StrongSwan: Safe passage across dangerous ground
The Inernat: Problems lurking everywhere!
Maybe you'd just want to say: “Objection! After all,
the situation isn't that bad!”
Generally speaking I'd concede that to you, because if things had been that
evil, the Internet would have been shut down a long time ago. However, things
are not at all hunky-dory, because problems are present en masse on the 'Net,
be it some botnets that are used for any suspicious activities, be it any spam
belchers that attempt to unload their junk anywhere – up to hijacked servers or
such that are explicitly run by any crooks to foist malicious software upon
others.
You therefore can compare the 'Net to a river at whose one bank you are
standing and at whose other one your destination is located. Unfortunately a
ford is your only way to cross, and on top of that the river is infested with
hungry crocodiles and piranhas, but also a lot of leeches and germs can be
found therein, that is, anything that can thoroughly mar one's delight – and no
bridge to be seen far and wide.
Unfortunately the problem with all this caboodle is that one knows that it's
there, but one never can tell if, and if yes, when, it strikes. One could of
course play safe and refrain from a passsage, but unfortunately you aren't
going to reach your destination this way. And if one wants to reach his
destination that any fiends attempt to breach, one has to risk the passage
willy-nilly, with all the problems that come along with it.
Now one could attempt to reach one's destination by boat since applications
like HTTPS definitely provide some means of protection that are supposed to
protect from bad surprises, but what if this boat all the sudden starts to
wallow (e. g. the so-called
POODLE attack
or the
Heartbled bug)?
This is only of provisional help when one lands oneself with problems once
again.
Furthermore n different applications thet implement
their security measures themselves offer a corresponding number of attack
vectors for any imbeciles, and you have to keep them
all up to date in order to avoid any problems – or at
least any libraries needed by such applications that take on the task of
encrypting and decrypting.
Bridging the gap
It would be extremely helpful to avoid this ford and build a bridge instead to
avoid any such problems in the first place. This way you can lock out any
repulsive creeps while you safely bridge the dangerous river.
Your destination may e. g. be a rented server that you wish to access. Instead
of banking on on a boat (e. g. SSH, etc.) which always turns out to be a
rewarding target for any attackers you instead build a secured connection on
which you are able to do as you like. It is furthermore not necessary any more
that the programs used don't have to implement any security measures
themselves; the protection is already offered by this bridge. This allows for
logging in to the server for example via Telnet without having to fear any
problems when working on an IPsec connection. In contrast to this it would be
absolutely irresponsible to generally open Telnet to the Internet, because that
would immediately render your server unprotected, plus the entire communication
could be read along, including any credentials.
And should the bridge turn out to be unstable because StrongSwan contains a
security flaw it entirely suffices to update one single spot to resolve the
problem instead of many.
How IPsec can protect you
As has been described in the chapter
Countermeasures IPsec protects you
threefold against bad surprises. It forces that each subscriber of an IPsec
connection be able to identify itself in respect to the other subscribers.
Unknown stations cannot surreptitiously join an IPsec network, and any bad eggs
can easily be detected and removed.
It also ascertains the integrity of the transmitted data and renders it
virtually impossible to forge the data sent across an IPsec connection – at
least this can only be done with an effort that's completely disproportionate
to its benefit. This guarantees that the data reaches its destination exactly
the way it has been sent.
Thirdly the IPsec connection prevents reading along the data by a third party,
because outsiders recognize the data stream to be noise rather than a normal
data connection: That which is happening on the connection remains entirely
hidden.
This renders the IPsec connection tamperproof, and should anyone nevertheless attempt this, he only triggers an error which causes your connection to abort. This will give you a warning in advance, especially when this happens repeatedly although the physical connection to the 'Net is stable enough to not be the explanation for the aborted connection.
to the topWhat IPsec cannot protect you from
However, IPsec has some limitations. Though IPsec is best suited for securing a
connection between two boxes against eavesdropping and manipulation, it doesn't
provide any protection against malicious data that enter your IPsec connection
by regular means, e. g. within the scope of a download or an e-mail that you
retrieve from your mail server. To counter this, entirely different measures
are necessary than those that IPsec could offer.
Let's consider the following scenario: In order to download some data from
anywhere you establish an IPsec connection to your server that also serves as
an IPsec gateway. Since the target server normally isn't identical with your
IPsec gateway the data stream needs to return to the unprotected part of the
'Net and then needs to find its way to its destination. Now there are various
possibilities to catch a Tartar, e. g. a compromised server that doesn't (just)
return the requested data but instead attempts to foist a
trojan upon you,
because someone has zeroed in on the bank details, etc. of an unwitting user.
Here the data returned by the server has resulted from a previous request and
is therefore considered legitimate by the IPsec gateway and so is sent across
the secured connection – and all the sudden your computer has contracted this
critter.