IPSec by stariya

VIEWS: 10 PAGES: 12

									                                    DFWUUG SECURITY SIG



IPSec VPNs – Industrial Strength Security For an Insecure In-
                           ternet
                                        INTRODUCTION
Companies, research institutions, and government organizations have long maintained private
networks between central offices and branch offices. These entities would lease expensive pri-
vate lines from communications companies between the central office and the branch locations.
Times have changed and communications have changed as well. Employees/contractors want to
work from home or external offices. Road warriors, all the way from salesmen to CEO’s, want to
be mobile and connect to the home office for whatever purpose. As the number of individuals
wanting remote access has increased, so to have the options of connecting to the central office
increased. There are fast, cheap, and plentiful connections to the Internet to be had in locations as
varied as libraries, airports, and Starbucks. Even Mickey D’s is getting on the bandwagon by of-
fering Internet connectivity at Mickey’s restaurants. Even though T1 and higher speed lines’
prices have dropped, they still vastly more expensive than a cable modem or ADSL line. Even
though an ADSL user can get 768K down and 128K up for about $30 a month, there’s this little
devil in the details called “security”. How do you go about securing what is basically an unse-
cured medium? Enter VPNs (Virtual Private Networks) and secure tunneling. Where physical
private networks existed, VPNs are becoming commonplace not only among road warriors,
branch offices, and central offices but also business-to-business partners exchanging data through
a secure tunnel wrapped around the communications traffic.


                                      VPN TOPOLOGIES
There are a number of ways to categorize VPNs. One way is by the type of connection or topolo-
gy of the network.
     Network-to-Network: This is also known as site-to-site. This type most often refers to a
        VPN between two geographically separate private networks. This type of VPN is com-
        monly used when the LANs have to be connected across a public network so that users on
        both networks can access resources located on the other LAN as if they were located on
        their own network. A major advantage is that in this configuration the networks appear to
        be adjacent to each other and the background operation of the VPN gateways is transpa-
        rent to the end users.
     Host-to-Network: The host-to-network scenario occurs when remote users connect to the
        corporate network over the Internet. The remote user first establishes an Internet session
        with the corporate VPN gateway. Once authentication operations are done, a tunnel is es-
        tablished over the Internet and the client becomes just another system on the internal net-
        work. This has become the growing practice for employees working from home or road
        warriors out in the field.
     Host-to-Host: This scenario involves two hosts. In such a configuration the tunnel be-
        tween the hosts encapsulates all the communications between them. Needless to say this
        is not a common occurrence. However, an example of such a configuration might be a



Dallas/Fort Worth Unix Users Group – Security SIG                                            Page 1
                                                                                      August 2004


       remote backup storage server located in a geographically distant location, such as a hot
       backup site.


                              VPN TUNNELING PROTOCOLS
Another way to categorize VPNs is by the tunneling protocol they use to secure communications.
    IPSec: IPSec is the most widely used of the VPN protocols. This is because it is the most
      standardized and supported of all the VPN tunneling protocols. IPSec is part of the IETF
      IPv6 standard and has been back-ported into IPv4. IPSec’s open standards have produced
      a suite of protocols that can be run on top of existing IP connectivity. It provides both au-
      thentication and encryption services and can be implemented on any almost any device
      that communicates over TCP/IP. The protocol incorporates three major components:
          o IKE: Internet Key Exchange
          o ESP: Encapsulated Security Payload
          o AH: Authentication Header
      IKE negotiates the security associations that describe the use of security services between
      participating entities. ESP provides confidentiality, data origin authentication, integrity,
      and optional anti-replay service. The AH is added after the IP header and provides packet-
      level authentication and integrity services ensuring the packet was not tampered with
      along the way and originated from the expected sender.
    PPTP: Point-to-Point Tunneling Protocol is a proprietary protocol of Microsoft intended
      for VPN-like communications. The protocol lacks the flexibility of other solutions and
      does not possess the same level of interoperability of other VPN protocols. PPTP is
      commonly used to create secure communications between large numbers of Windows
      hosts on an intranet. PPTP has a long history of insecurities.
    L2TP: Layer 2 Tunneling Protocol can be thought of as Son of PPTP. It was birthed by
      the tripartite mothers of Cisco, Microsoft, and 3Com. The protocol does not offer encryp-
      tion by itself but can be used with other protocols or application-level encryption to pro-
      vide for security needs. L2TP is best combined with IPSec.
    SSL: Secure Socket Layer. A VPN technology that has been growing in popularity is the
      Secure Sockets Layer (SSL) VPN. A big advantage of SSL VPNs is that you don’t need
      special VPN client software on the VPN clients. That’s because the SSL VPN uses the
      Web browser as the client application. Thus, SSL VPNs are known as “clientless” solu-
      tions. This also means the protocols that can be handled by an SSL VPN are more li-
      mited. However, this can also be a security advantage. With SSL VPNs, instead of giving
      VPN clients access to the whole network or subnet as with IPSec, you can restrict them to
      specific applications. If the applications to which you want to give them access are not
      browser-based, however, custom programming might be necessary to create Java or Ac-
      tive-X plug-ins to make the application accessible through the browser. A disadvantage of
      this is that in order to use such plug-ins, the client’s browser settings will have to be
      opened up to allow active content – thus exposing the browser to malicious applets unless
      you set it to block unsigned active content and ensure that the plug-ins are digitally
      signed.


Dallas/Fort Worth Unix Users Group – Security SIG                                          Page 2
                                                                                       August 2004




                  IPSEC OPERATIONS AND MODES – AN OVERVIEW
As mentioned earlier, the IPSec protocol consists of several parts that define two security proto-
cols, AH and ESP.
     ISAKMP is a framework for management of keys and other vital information such as se-
       curity associations.
     IKE provides the cryptographic algorithm negotiation and key distribution utilized by AH
       and ESP,
     ESP provides data origin authentication, connectionless integrity, anti-replay service, and
       data confidentiality.
     AH provides data origin authentication, connectionless integrity, and anti-replay service.

                                       Security Associations
Both AH and ESP rely on security associations (SAs) negotiating the properties of a secure con-
nection using IKE. The SA holds the information negotiated between the two VPN participants.
Such information includes cryptographic keys and their lifetimes, cryptographic algorithm used,
IPSec protocol, and its mode of operation. For each mode of operation, two SAs are required, on
for incoming traffic and another for outgoing traffic. This is called an SA Bundle. If both AH and
ESP are used, there would have to be four SAs. Each SA is uniquely identified with a SPI (Secu-
rity Parameter Index). An important characteristic of an SA is its lifetime. This lifetime parame-
ter specifies the time interval after which the SA must be renegotiated or terminated. The lifetime
is specified either as a number of bytes processed or a time interval. Each host participating in the
communication stores SA information in its SAD (Security Association Database).

                                        ISAKMP and IKE

ISAKMP (IPSec Key Exchange and Management Protocol) is part of the IPSec suite that defines
procedures for negotiation, establishment, modification, and deletion of SAs. ISAKMP defines a
general framework that is independent of cryptographic algorithms or authentication methods. As
such, it is rather abstract in its application. IKE (Internet Key Exchange) is based on the
ISAKMP framework. IKE consists of two different mode or phases. Phase 1 is used to establish a
secure channel later used to protect all negotiations in Phase 2. Phase 2 is used to negotiate the
IPSec SAs to set up the IPSec tunnel to protect the communications traffic.

Usually the IKE protocol is not implemented by the operating system itself but by an external
daemon. For example, FreeS/WAN uses Pluto. The new Linux kernel uses Racoon, the IKE
daemon of the KAME project. This daemon communicates using the IKE protocol and creates
IPSec SAs as needed.




Dallas/Fort Worth Unix Users Group – Security SIG                                            Page 3
                                                                                      August 2004


                                               ESP
ESP provides for encapsulation of the unprotected IP packet, its encryption, and authentication.
Traditionally, IPSec uses DES or 3DES (Triple DES) encryption. Recently, DES has come under
fire for being too easy to break. As such, it is like to retired as an acceptable strong encryption
algorithm. 3DES, or “DES on steroids,” provides much stronger encryption than plain DES, but
it is a more mathematically demanding algorithm and is quickly drains the life out of older PCs,
or handheld devices. Some newer IPSec implementations use stronger algorithms such AES,
Blowfish, and Twofish.

                                              AH
AH allows you to check the authenticity of the data and the header of the IP packet sent to you. It
does not provide a mechanism for data encryption but does provide a hash that code that allows
you to check whether the packet was tampered with along the way. This form of encapsulation
alone has gained rather limited use as more people tend to use ESP alone or ESP combined with
AH.

                                        IP Compression
As you might guess, all this extra security comes at the price of extra encapsulation of the IP
packet. This translates into decreased throughput. IPSec seeks to overcome this problem with a
built-in IP compression protocol.

                                      LINUX AND IPSEC
It used to be that the only IPSec game in town for Linux was FreeS/WAN.
(http://www.freeswan.org). John Gilmore started FreeS/WAN in 1996. The S/WAN part of the
name stands for Secure Wide Area Network. The Free part indicates that it was distributed under
the GPL. It was difficult to shoehorn into Linux and even more difficult to set up. For reasons
best known to the kernel mavens of Linux and the FreeS/WAN group, it was never merged into
the normal Linux source tree. Early in 2004, the FreeS/WAN development team closed up shop
but the project re-emerged with some of the original developers as OpenSWAN
(http://www.openswan.org). In the meantime, numerous individuals have been working to put
IPSec support into the Linux source tree.

                           Configuring the Linux Kernel with IPSec

With the release of the 2.6 kernel, IPSec is part of the Linux kernel. The following figure shows
the options that should be enabled in xconfig to build a kernel with IPSec support. Choosing
these options will also enable the proper cryptographic functions in the kernel build process as
well.




Dallas/Fort Worth Unix Users Group – Security SIG                                          Page 4
                                                                                     August 2004




                          Figure 1 – Configuring IPSec into the Kernel



After enabling any other options of interest, make the kernel in the usual manner.


                             SETTING UP A VPN WITH IPSEC
Recall the Buffy-verse network from last time shown in Figure 2. We want to setup a VPN using
IPSec between sunnydale.com and elay.com. We will set up configuration files on
giles.sunnydle.com and wesley.elay.com.




Dallas/Fort Worth Unix Users Group – Security SIG                                        Page 5
                                                                               August 2004




                                  Figure 2 – The Buffy-verse

On giles.sunnydale.com, we set up the following file /etc/manual-setkey.conf




Dallas/Fort Worth Unix Users Group – Security SIG                                  Page 6
                                                                                     August 2004


# Clear the SAD and SPD
flush;
spdflush;


# Create the IPsec SAs
# add <IP> <IP> <protocol> <SPI> -m <mode> -E <algorithm> <key>
add 5.0.0.1 3.0.0.1       esp 0x200 -m tunnel -E 3des-cbc
  0x3f0b868ad03e68acc6e4e4644ac8bb80ecea3426d3d30ada
  -A hmac-md5 0xbf9a081e7ebdd4fa824c822ed94f5226;
add 3.0.0.1 5.0.0.1       esp 0x200 -m tunnel -E 3des-cbc
  0x3f0b868ad03e68acc6e4e4644ac8bb80ecea3426d3d30ada
  -A hmac-md5 0xbf9a081e7ebdd4fa824c822ed94f5226;


# Create the security policies for the networks
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
             esp/tunnel/3.0.0.1-5.0.0.1/require;


spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
             esp/tunnel/5.0.0.1-3.0.0.1/require;


Looking at the file’s directives, the flush and spdflush clear out the SAD and the SPD respective-
ly. Next we want to add two IPSec SAs with the add command. We add an SA between 5.0.0.1
and 3.0.0.1 using the ESP protocol with a security parameter index of x200. We specify a mode
with the –m switch of tunnel. For an encryption algorithm, we use the –E option specifying
3DES encryption with CBC (Cipher Block Chaining) followed by the encryption key. Next the –
A option specifies authentication method, hmac-md5, and the authentication key. The hmac-md5
stands for Hashed Message Authentication Code using the MD5 hashing algorithm.

The next line sets up another SA with the same parameters except that second is between
3.0.0.0.1 and 5.0.0.1 instead of 5.0.0.1 and 3.0.0.1 in the first one. Recall we need two SAs for
communication.

The next line creates an entry in the SPD from the source range (10.0.1.0/24) to the destination
range (10.0.2.0/24). Any protocol traveling between the two VPNs will have the security policy
specified by –P. The –P specifies the direction (out) and requires that ESP be applied to the tun-
nel between 3.0.0.1 and 5.0.0.1.

The next line creates another entry in the SPD but is reversed from the previous one; going out is
reversed to coming in.



Dallas/Fort Worth Unix Users Group – Security SIG                                         Page 7
                                                                                    August 2004


Let’s look at the /etc/manual-setkey.conf file on wesley.elay.com.
# Clear the SAD and SPD
flush;
spdflush;


# Create the IPsec SAs
# add <IP> <IP> <protocol> <SPI> -m <mode> -E <algorithm> <key>
add 5.0.0.1 3.0.0.1        esp 0x200 -m tunnel -E 3des-cbc
  0x3f0b868ad03e68acc6e4e4644ac8bb80ecea3426d3d30ada
  -A hmac-md5 0xbf9a081e7ebdd4fa824c822ed94f5226;
add 3.0.0.1 5.0.0.1        esp 0x200 -m tunnel -E 3des-cbc
  0x3f0b868ad03e68acc6e4e4644ac8bb80ecea3426d3d30ada
  -A hmac-md5 0xbf9a081e7ebdd4fa824c822ed94f5226;


# Create the security policies for the networks
spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
              esp/tunnel/3.0.0.1-5.0.0.1/require;


spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
              esp/tunnel/5.0.0.1-3.0.0.1/require;


If you do a diff of the two files, you get the following result:

14c14
< spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
---
> spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
17c17
< spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
---
spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec


The difference is the direction.

To start the VPNs do /sbin/setkey –f /etc/manual-setkey.conf
This will set up the SAs and policies and start up the encrypted tunnel between the VPNs.

Using ethereal, you can see that the packets are encrypted and thoroughly unrecognizable.


Dallas/Fort Worth Unix Users Group – Security SIG                                           Page 8
                                                                                       August 2004




                  Figure 3 – Ethereal Showing ESP Traffic Between Two VPNs

This manual keying has some drawbacks: it’s error prone and a hassle for the administrators of
giles.sunnydale.com and wesley.elay.com. A more automatic method would be desirable.

The solution is the usage of the IKE protocol. For Linux, the IKE daemon is racoon. This IKE
daemon first authenticates its peer. It then negotiates the IPSec protocols and algorithms using
proposals. Then it creates the symmetric keys for the authentication and encryption of the proto-
cols. These keys are automatically re-keyed by racoon. The authentication can be based on shared
secrets (like passwords), Kerberos, and X.509 certificates. Almost all known encryption and au-
thentication algorithms are supported by racoon.

For communications in the Buffy-verse, we will use pre-shared keys (PSK) for the authentication
of the peers. The PSK has to be stored in a separate file /etc/psk.txt. The file looks like this for
giles.sunnydale.com:



Dallas/Fort Worth Unix Users Group – Security SIG                                           Page 9
                                                                                    August 2004


#IP Address                   PSK
5.0.0.1                       Into every generation a Slayer is born.


The /etc/psk.txt for wesley.elay.com looks like this:

#IP Address                   PSK
3.0.0.1                       Into every generation a Slayer is born.


An administrative tip: make the permissions on /etc/psk.txt 600.

The first column can either hold an IP address, an email address, or an FQDN. Everything start-
ing at the second column is used as secret and can either be ASCII or a hexadecimal starting with
0x.

Now we need to configure raccoon. Here is the /etc/raccoon.conf file for giles.sunnydale.com

path pre_shared_key "/etc/psk.txt";


remote 5.0.0.1 {
          exchange_mode main;
          proposal {
                    encryption_algorithm 3des;
                    hash_algorithm md5;
                    authentication_method pre_shared_key;
                    dh_group 2;
          }
}


sainfo address 10.0.1.0/24 any address 10.0.2.0/24 any {
          pfs_group 2;
          encryption_algorithm 3des;
          authentication_algorithm hmac_md5;
          compression_algorithm deflate;
}


Similarly, we need a /etc/racoon.conf file for wesley.elay.com:

path pre_shared_key "/etc/psk.txt";



Dallas/Fort Worth Unix Users Group – Security SIG                                       Page 10
                                                                                     August 2004



remote 3.0.0.1 {
          exchange_mode main;
          proposal {
                    encryption_algorithm 3des;
                    hash_algorithm md5;
                    authentication_method pre_shared_key;
                    dh_group 2;
          }
}


sainfo address 10.0.2.0/24 any address 10.0.1.0/24 any {
          pfs_group 2;
          encryption_algorithm 3des;
          authentication_algorithm hmac_md5;
          compression_algorithm deflate;
}


As before, note the reversals between the two.

Racoon does not start the connection by itself, like FreeS/WAN does. For Racoon to start the
connection, it must be asked. This is accomplished by the Linux kernel. Whenever the Linux
kernel encounters a packet that must be encrypted according to the security policies, but no secu-
rity association defining the keys and algorithms exists, the kernel calls Racoon. It is now Ra-
coon's task to authenticate the peer and to create the appropriate SAs.

Now that racoon is taking over the task of key management, we can greatly simplify out setkey
configuration. For giles.sunnydale.com, the new setkey.conf file looks like this:

# Flush the SAD and SPD
flush;
spdflush;


# Security policies for racoon
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
              esp/tunnel/3.0.0.1-5.0.0.1/require;


spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
              esp/tunnel/5.0.0.1-3.0.0.1/require;


Dallas/Fort Worth Unix Users Group – Security SIG                                        Page 11
                                                                                     August 2004



Similarly, the setkey.conf file for wesley.elay.com looks like this

# Flush the SAD and SPD
flush;
spdflush;


# Security policies for racoon
spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
              esp/tunnel/3.0.0.1-5.0.0.1/require;


spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
              esp/tunnel/5.0.0.1-3.0.0.1/require;


Now the administrators on giles.sunnydale.com and wesley.elay.com kick off the VPNs with
these commands:

setkey -f /etc/auto-tunnel-setkey.conf                 ;   racoon     -F   -f   /etc/transport-
racoon.conf


The –F option to racoon tells it to run in foreground mode. This way, all the informational output
can be seen.




                                         CONCLUSION

IPSec VPNs provide strong security for business-to-business and person-to-business needs. IP-
Sec has two protocols, AH and ESP, that give confidentiality, integrity, and authentication. IPSec
also has protocols and frameworks for key negotiation and data compression. FreeS/WAN used
to be the only IPSec game in town as far as Linux was concerned. With the advent of the 2.6 ker-
nel series, there is now integrated support for IPSec in the kernel in addition to the survivor of
FreeS/WAN, OpenSWAN.




Dallas/Fort Worth Unix Users Group – Security SIG                                        Page 12

								
To top