StrongSwan: Countermeasures
Dealing with the problem
If it's about preventing anyone from reading along data streams or possibly
tampering with them independently of the application being used, that's where
IPsec comes into play.
No matter which solution you choose, they all have in common that they
intercept the data stream directed at the Internet and redirect it to a secured
connection. In order to do this it is necessary to set up IPsec at both
endpoints of the connection that you intend to secure.
Once this is done, IPsec ensures that the data stream can only be attacked with
considerable effort, if at all. To this end it makes use of three distinct
methods that all have to come together in order to maximize security without
limiting the usability of the applied measures. After all, any security
measures are only as good as it can be handled by the user who has to deploy it
- and a user overburdened with these security measures inevitably leaves holes.
How things are done is described using the example of StrongSwan to which you
can find plenty of information
on the site of the project. At the first glance setting this IPsec solution
seems to be incomprehensible, but since it followes a particular pattern, any
difficulties can be solved rather easily.
Like every sensible security solution StrongSwan targets three distinct aspects that are all meshed in order to achieve a maximum gain in security. These are the following aspects:
- Authentication
- Integrity checks
- Encryption
If even one of these components is inadequate or not present, that inevitably
means a significant loss in security. Even though a data stream is secured
against inspection by a third party and cannot be attacked from the outside,
what's the sense behind all this if others can freely connect to the secured
channel and so nevertheless can read along?
And what sense do access controls and encryption make when integrity checks are
missing and the data stream can thus be subject to attacks?
Or why implementing access controls and integrity checks when the data is
transferred in cleartext so that everybody may read along?
As you see there's a triangle relationship between all three security aspects: If even one of these components is inadequate, the rest falls apart as well, and one could discard the affected security solution in the first place. The bottom line would be that any idiots would have as much a walk-over as before, but you wouldn't have to put up with it.
to the topAuthentication
For the security measure to have effect it is necessary to ensure that the party that wants to connect to a secured channel actually has permission to do so. After all a secured connection isn't meant for everybody, and any unidentified people could easily cause mischief. However, that's not the purpose of this exercise.
To guarantee authenticity StrongSwan offers various means to determine the authorization status of a station. The following authentication methods are available:
Mode | Meaning |
---|---|
X.509 | Identification by means of certificates |
PSK | Identification by means of pre-shared keys |
EAP | Identification by means of specific credentials that can be performed either directly by StrongSwan or relayed to an external server process that performs the authentication. There are several methods available for transmitting the credentials. |
Some of the methods mentioned can be set up rather easily and offer adequate
protection, especially when the number of authorized persons is rather limited.
Otherwise more sophisticated methods are required that may be more difficult to
implement, but that are significantly more flexible to handle and allow for
quick reactions.
Things are much simpler if a dedicated process is taking care of checking any
credentials whereas StrongSwan merely checks the validity of any provided
certificates, plus that you don't have to restart StrongSwan in case you need
to change anything related to the credentials.
Integrity checks
Anyone working on a secure channel must be sure that the data that he transmits
there is reaching its destination ecactly how he has sent it and that anything
he receives has been sent the same way as it is arriving.
To this end a signature is attached to every transmission that permits
StrongSwan to determine whether or not anyone has unsolicitedly modified the
data. For this a bunch of more or less powerful algorithms that calculate a
checksum that is transmitted together with the data being sent exist. It is
thereby true that such a hash is more secure the more powerful the function
generating it is.
Hence a hash is normally calculated quickly with MD5 or SHA1, but it may be
attacked rather easily since it is far too short by current standards and
therefore a collision of hashes, that is, different data streams that produce
identical hashes, can be effected rather
easily. However, when using e. g. SHA512 things become substantially
more difficult, because the hash is significantly longer and collisions
therefore occur much more rarely. In order to be safe rather than sorry it is
recommended to use the best algorithm available for generating the hash.
Encryption
After all, when working on a secured channel, one wouldn't want others to see
which data is traveling on it. Here encryption algorithms come into play that
encrypt the data stream at the sender's side and decrypt it at the recipient's
side. This way one can be sure that there isn't anyone who could happen to read
along the data stream, and even if someone should be recording it for later
analysis, he won't be able to decrypt it in an acceptable amount of time. This
way data may be transferred in cleartext via the secured connection –
encrypting the connection ensures that it cannot be seen from the outside and
so prevents anyone from abusing it.
Thus one can resort to insecure means in order to log in to a remote box, for
example Telnet even though that's something that's best avoided under normal
circumstances. You normally would have SSH as a substitute which,
when properly set up, proves to be a nearly
invincible obstacle for any attackers. However, using Telnet via an IPsec
tunnel can be considered equally safe.
On top of that you may even export an
NFS inside an IPsec tunnel
to access another box as if it were a local directory. This way you don't have
to log in to the remote computer, but you nevertheless gain access to any files
in the exported directory as if you had logged in there.