Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Deployment Scenario
IPsec can secure all of the traffic between two systems, between specific ports, or between specific boxes. The traffic can be bypassed (that is, it is not encrypted) or dropped. SSL secures traffic mainly between client and server application components.
In the following deployment example, an iPlanet™ web proxy server is deployed outside the internal firewall. The proxy server uses an iPlanet LDAP server to authenticate users. The user ID and password information are transmitted without encryption. Therefore, someone inside the enterprise could snoop the traffic for passwords. In addition, the version of the proxy server cannot communicate over SSL to LDAP.
A servlet or JavaServer Pages software is deployed on a web container using Java™ Database Connectivity ("JDC™") software to communicate to an RDBMS server on a different machine. The traffic between the web container box and the RDBMS server box needs to be secure.
IPsec Configuration
The IPsec configuration required for the deployment example involves setting up an IPsec policy file and the keys for encryption and creating cryptographic hashes. This section contains procedures to set up the policy file and keys, to create the hashes, to test the setup, to enable it, and to check the status of the network traffic.
The examples in this section are shown using DES encryption. It is recommended to use 3DES, AES, or Blowfish. The availability of these encryption algorithms could be different on different versions of the operating system.
To Set Up the IPsec Policy File
The ipsecconf(1M) utility (/usr/sbin/ipsecconf) configures the IPsec policy file for a host. After the policy is configured, all inbound and outbound datagrams are subject to policy checks. If no entry is found, no policy check will be completed, and all of the traffic will pass through. The policy is configured in the /etc/inet/ipsecinit.conf file. Each entry protects traffic in one direction. For details on the syntax of the entries, refer to ipsecconf(1M). A sample policy file, /etc/inet/ipsecinit.sample, is available in the Solaris OS.
Copy and rename the ipsecinit.sample file to /etc/init/ipsecinit.conf.
Edit the file to add your requirements.
Load the policy file by typing:
The following is a sample entry in the policy file.
{dport 23} apply {encr_algs des encr_auth_algs md5 sa shared}
{sport 23} permit {encr_algs des encr_auth_algs md5}
The above entry secures telnet(1) traffic (port 23) with DES encryption and MD5 for hash. The first entry applies to the outbound traffic to be encrypted with DES. The second entry applies to the inbound traffic.
$ ipsecconf -a /etc/inet/ipsecinit.conf
The policy file needs to be set up on both systems. The manual key file is identical on both machines—only the policy differs (that is, source and destination entries).
IPsec Keys
In an IPsec deployment for a financial company, the /usr/sbin/ipseckey command was used to set up manual key information for the communicating hosts.
The Solaris 8 OS does not provide automated key management. The Solaris 9 OS provides IKE-based key management. When creating keys, take care to provide the proper key length. For example, DES requires a 64-bit key, and 3DES requires a 192-bit key. MD5 requires a 128-bit key, and SHA-1 requires a 160-bit key. When you translate these into, for example, hex digits, 3DES would have 48-hex digits and SHA-1 would have 50 digits.
For the Solaris 8 OS, you can use the output from an od -x < /dev/random command to generate random digits and to get as many numbers as are required by the encryption, hashing algorithm. The following is sample random output.
# od -x </dev/random | head -4 0000000 89e9 f7d5 d1da 3a51 7805 44fb 6b44 e442 0000020 fbb8 ffd4 4835 58c6 10b2 cd35 a783 68ed 0000040 d726 15ff 22f1 32d3 e2ae 72a0 f847 ee17 0000060 f13d 8dfb 0539 cc41 4871 d40a cd43 7814
A sample key file consists of the following code.
add esp spi 1135 src 100.27.364.17 dst 19.15.57.46 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012 add esp spi 1138 src 19.15.57.46 dst 100.27.364.17 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012
The first entry adds ESP as the IPsec protocol (AH is the other option) between two systems with IP addresses 100.27.364.17 and 19.15.57.46. The hash algorithm is SHA-1, and the encryption algorithm is 3DES. You can observe 40 digits in authkey (that is, 160 bits for SHA-1) and 48 digits in encrkey (that is, 192 bits for 3DES). The security parameter index (SPI) number is 1135. This is an arbitrary number. The SPI number should match between the two systems. For detailed syntax of the policy file, refer to ipseckey(1M).
Load the keys with the following command. Provide the correct path name for the keyfile with the -f argument.
# ipseckey -f keyfile.myhost
Sample IPsec Configuration
This section contains a sample IPsec configuration between 19.15.57.46 and 100.27.36.17 to encrypt LDAP traffic, but to bypass HTTP traffic.
The following is the policy file in 19.15.57.46.
{sport 8080} bypass {dir out}
{dport 8080} bypass {dir in}
{daddr 19.15.57.46 sport 389} apply {encr_algs 3DES encr_auth_algs
sha1 sa shared}
{saddr 19.15.57.46 dport 389} permit {encr_algs 3DES
encr_auth_algs sha1}
The following is the key file in 19.15.57.46.
add esp spi 1135 src 100.27.36.17 dst 19.15.57.46 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012 add esp spi 1138 src 19.15.57.46 dst 100.27.36.17 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012
The following is the policy file in 100.27.36.17.
{sport 8080} bypass {dir in}
{dport 8080} bypass {dir out}
{daddr 100.27.36.17 dport 389} apply {encr_algs 3DES
encr_auth_algs sha1 sa shared}
{saddr 100.27.36.17 sport 389} permit {encr_algs 3DES
encr_auth_algs sha1
The following is the key file in 100.27.36.17.
add esp spi 1135 src 100.27.36.17 dst 19.15.57.46 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012 add esp spi 1138 src 19.15.57.46 dst 100.27.36.17 auth_alg sha1 authkey bde359723576fdea08e56cbe876e24ad0123456 encr_alg 3des encrkey 8bd4a52e10127deb4057210346122e1f283cb644d2c88012
To Sanity Test IPsec
Capture snoop(1M) output between the two systems before IPsec is enabled, as in:
Use the application (for example, the proxy authenticating to LDAP).
# snoop -v -o snoop.out fromsystem tosystem
To Enable IPsec
Capture snoop(1M) output between the two systems after IPsec is enabled, as in:
Use the application.
# snoop -v -o snoop.out fromsystem tosystem
You should observe the ESP packets in the post IPsec traffic. The snoop(1M) output should be similar to the following.
IP: ESP: ----- Encapsulating Security Payload ----- ESP: ESP: SPI = 0xa8dccd8e ESP: Replay = 9 ESP: ....ENCRYPTED DATA....
This example shows that the packets are encrypted and that there is no plain text data.
The following command can be used for status reports.
# ndd /dev/ipsecesp ipsecesp_status ESP status ---------- Authentication algorithms = 2 Encryption Algorithms = 3 Packets passing authentication = 0 Packets failing authentication = 0 Packets apparently decrypting badly = 0 Packets failing replay checks = 0 Packets failing early replay checks = 0 Failed inbound SA lookups = 80 Inbound PF_KEY messages = 12 Inbound ESP packets = 80 Outbound ESP requests = 78 PF_KEY ACQUIRE messages = 23 Expired associations (# of bytes) = 0 Discarded inbound packets = 80