Less known Solaris features: IPsec
The secrets of root
There were other systems with other roots, other priests and other believers. But how should they communicate with each other without put their secrets in danger. Some chants and documents were really precious. The messenges of root had to be sure, that they gave the chants to the roots with the same belief. But the messengers had another problems: There were many bandits on their way to the other systems. And it was unthinkable that a mere bandit would know the secrets of root. Foundations
This will the only article in this series without an explanation of the technologies. I could write for days about it and still leaving out important things. Instead of this, please look at the links section at the end of the article. Only some short words about this topic. Encryption is essential in networking. The Internet is a inherently insecure media. You have to assume, that you don´t talk to the right person as long as you didn´t authenticated him, you have to assume, that the data will be read by someone as long you won´t encrypt the data. IPSec solves this problems. I won´t tell you that IPsec is an easy protocol. The stuff around IPSec is defined in several RFC and the documentation is rather long. The encryption itself isn´t the complex part. But you need a key to encrypt your data. And there starts the complexity. It´s absolutly essential, that this key stays secret. How do you distribute keys through an inherently unsecure transport channel. And the next problem: How do you negotiate the encryption mechanism? And how to ensure, that you talk with the right system ? Problems … problems … problems! IPsec solves this problems. IPsec isn´t a single protocol. It´s a suite of protocols consisting out Internet Security Association and Key Management Protocol, this protocol build on the protocol for Internet Key Exchange, this protocol is based on the Oakley protocol. And fhere is a whole wad of further protocols and mechanisms and algorithms to ensure secure communication. IPsec in Solaris
Okay, but now i want to give you an example to configure IPsec on Solaris. Although the matter is complex, it isn´t hard to use IPsec within Solaris. IPsec is a rather old feature in Solaris. We´ve introduced it in Solaris 8 and improved the implementation since this time. So this implementatio is now in year eight of it´s availability. Example
The task for this example is to secure all traffic between two hosts. I´ve used two VM with Solaris Express Build 78 for this configuration. (You need at least an Solaris 10 Update 4 for this tutorial. In this update the ipsecconf command was introduced making the configuration much easier)
theoden has the IP number
10.211.55.200. Gandalf has the IP number
10.211.55.201. I don´t want to use manual keying, instead of this the example will use self signed certificates.
Prepare the installation
At first: Obviously you have to change hostnames and ip numbers and names for certificate corresponding to your own site. We have to work on two hosts. It´s a best practice to open up two terminal windows. Get root in both of them. To keep things apart use the bash shell and modifiy the shell prompt:
Look at the login prompt in the examples. They designate on which system you have to work on.
Okay … at first you have to ensure, that the names of the systems can be resolved. It´s a good practice to put the names of the systems into the
Okay, we don´t want manual keying or some stinking preshares keys. Thus we need to create keys. Login to gandalf and assume the root role:
Do the same on the other host.
You need the output of this commands later, so past them to a texteditor or at a save place …
Configuration of IPsec
Okay, now we have to tell both hosts to use IPsec when they talk to each other:
This translates to: When i´m speaking to theoden, i have to encrypt the data and can use any negotiated and available encryptition algorithm and any negotiated and available authentication algorithm.
Such an rule is only valid on one direction. Thus we have to define the opposite direction on the other host to enable bidirectional traffic:
Okay, the next configuration is file is a little bit more complex. Go into the directory
/etc/inet/ike and create a file
config with the following content:
This looks complex, but once you´ve understand this it´s quite easy:
We use self-signed certificate. The certificate isn´t signed by an independent certification authority. Thus there is no automatic method to trust the certificate. You have to configure the iked explicitly to trust this certificates. This both lines tell the iked to trust the certificates with the alternate name 10.221.55.200 and 10.211.55.201. Where did this alternate names came from? You set them! Look in the command line for creating the certificate. You defined this name by using the
Now you define an key exchange. You have to give each connection an unique name. After this you define, what part of the certificate is used to authenticate the remote system. In this example we use the distingushed name. The local system identifies itself with the certificate named
C=de, O=moellenkamp, OU=moellenkamp-vpn, CN=gandalf to a remote system, and expect a trusted certificate with the distingushed name
C=de, O=moellenkamp, OU=moellenkamp-vpn, CN=theoden.
No the iked knows the ip addresses of the local and the remote host.
After defining the authentication credentials, we have to define how the system should communicate. This line means: Use the certificates to authenticate the other system. The key determination protocol is based on a prime number. We use md5 as the groundlaying algorithm to authenticate and 3des for encryption. This is the part where you configure the methods for authentication and encryption. They have to be the same on both hosts, otherwise they won´t be able to negotiate to a common denominator thus you won´t be able to communicate between the both hosts at all.
Now we do the same on the other system.
Obviously you have to swap the numbers for the local and remote system and you have to assign a unique label to it.
Okay, we are almost done. But there is still a missing but very essential thing when you want to use certifcates. We have to distribute the certificates of the systems.
At the beginning there is only the local key in the system. We have to import the key of the remote system. Do you remember the output beginning with
-----BEGIN X509 CERTIFICATE----- and ending with
-----END X509 CERTIFICATE-----? You need this output now.
The next command won´t come back after you hit return. You have to paste in the key. On gandalf you paste the output of the key generation on theoden. On Theoden you paste the output of the key generation on gandalf. Let´s import the key on gandalf
After pasting, you have to hit Enter once and after this you press Ctrl-D once. Now we check for the sucessful import. You will see two certificates now.
Okay, switch to theoden and import the key from gandalf on this system.
Activate the configuration
Okay, now we have to activate this configuration on both systems:
Check the configuration
Login into theoden as root and start a packet sniffer:
Okay … now login to gandalf and start some pings to theoden:
Okay, theoden can speak with gandalf and vice versa. But is it encrypted? In the terminal window for theoden the following output should be printed:
ESP stands for Encapsulated Security Payload. Mission accomplished.
Do you want to learn more?
System Administration Guide: IP Services » IP Security IPsec at Wikipedia
Internet Key Exchange
Internet Security Association and Key Management Protocol Other
An Illustrated Guide to IPsec