StrongSwan: Contre-mesures
Remédier ce problème
Lorsqu'il est en cause de prévenir suivre ou tripatouiller des trains de
données indépendant de l'application utilisée, il est
IPsec qui entre en jeu.
N'importe quelle solution vous allez choisir, elles ont tous en commun qu'elles
interceptent le train de données pointé vers l'Internet et le déroutent à
travers une connexion sécurisée. Il y est nécessaire de configurer IPsec aux
deux bouts de votre connexion à protéger.
Au moment de le faire, IPsec se soucie que si tant qu'on puisse attaquer le
train de données, il faut un conidérable effort. Il y se sert de trois méthodes
qu'il faut rejoindre pour garantir un maximum de sécurité sans que les mesures
prises empêchent l'utilité. En fin de compte chaque mesure de sécurité est
seulement si bon comme elle peut être appliqué par un usager – et un usager qui
est trop demandé par les mesures de sécurité laisse des trous.
Il est décrit comment ceci se déroule à l'exemple de StrongSwan pour lequel
vous pouvez
trouver
une plénitude d'information sur la page du projet. La configuration de ce
solution IPsec paraît incomprehensible a priori, mais comme elle suit un
particulier schéma, on peut résoudre des éventuelles difficultés assez
facilement.
StrongSwan, comme tout raisonnable solution de sécurité cible trois aspects que tous s'enchaînent pour garantir le plus grand gain de sécurité. Ils sont les aspects suivants:
- Authentification
- Vérification de l'integrité
- Chiffrage
S'il y a une seule part desquelles qui est insuffisante ou non present, ça
signifie une conidérable perte de sécurité. Même si le train de données est
protégé contre prise de connaissance par des tiers et ne peut pas être attaqué
de l'extérieur, quel est le sens de cela lorsque des tiers peuvent gagner
accès au canal protégé et donc suivre tout?
Ou quel est le sens du contrôle d'accès et le chiffrage lorsque le train de
données manque la vérification de l'integrité et peut donc être attaqué?
Ou à quoi servent le contrôle d'accès et la vérification de l'integrité lorsque
les données sont transmises en texte clair et chacun pourrait les suivre?
Comme vous voyez il y a une rélation triangulaire entre ces trous aspects de sécurité: S'il y a une composante qui est insuffisante, le reste faut aussi et on pourrait s'en dispenser pour commencer. Quelconques idiots ont en fin de compte beau jeu comme avant, mais vous n'auriez pas l'entier effort.
en hautAuthentification
Pour qu'une mesure de sécurité aie effet, il faut garantir que la partie qui veut connecter à un canal protégé est au fait autorisée pour ce faire. En fin une connexion protégée ne cible pas tout le monde, et des inconnus peuvent promptement faire des bêtises. Mais il n'est pas le sens de cela.
Pour garantir l'authenticité StrongSwan offre plein des options pour déterminer la légitimité d'une station. Vous avez les mesures de sécurité suivantes à choisir:
Procédure | Signification |
---|---|
X.509 | Vérification de l'identité par des certificats |
PSK | Vérification de l'identité par des clés partagées |
EAP | Vérification de l'identité à l'aide de paritculières identifiants que pourrait être ou conduite directement par StrongSwan ou redirigée à un processus serveur qui va conduire l'authentification. Il y a plusieurs méthodes pour transmettre les identifiants. |
Il y a quelques-unes méthodes qu'on puisse configurer avec peu effort qui
offrent de protection acceptable, en particulier lorsque le nombre des
personnes légitimées est calculable. Autrefois il faut des méthodes plus
sophistiquées que sont plus difficiles à implémenter, mais elles sont plus
flexible à appliquer et permettent réagir rapidement.
En outre il est plus simple lorsqu'il y a un processus spécialisé qui se soucie
de vérifier les identifiants tandis que StrongSwan seulement vérifie la
validité des certificats présentés, et puis il ne faut pas redémarrer
StrongSwan si vous avez modifié les identifiants.
Vérification de l'intégrité
Chacun qui travaille dans un canal sanctuarisé doit être sûr que les données
envoyées là-dedans arrivent à leur destination comme transmises et que tout
qu'il reçoit était transmis comme reçu.
Une signature digitale est y ajoutée à toutes transmissions, que permet
StrongSwan déterminer lorsque quelqu'un a illicitement modifié les données ou
non. Pour ce but il y a plusieurs algorithmes peu ou prou puissants qui
calculent une somme de contrôle qu'est envoyée conjointement avec les données
transmises. Une signature est plus sécuritaire le plus puissante la fonction
qui la génère.
Une signature est normalement créé rapidement avec MD5 ou SHA1, mais on la
pourrait attaquer comparativement facilement comme elle est trop courte de nos
jours et une collision des signatures, soit des trains de données différents
qui produissent des signatures identiques,
est effectuée assez facilement.
Lorsqu'on applique par contre SHA512 l'entière affaire devient fortement plus
difficile, parce que la signature est plus long par une magnitude et des
collisions se produissent considérablement moins souvent. Pour se assurer il
est recommandé de prendre le meilleur algorithme pour produire la signature
digitale.
Chiffrage
Lorsqu'on travaille sur un canal sanctuarisé, on certainement ne veut pas que
quelques personnes captent quelques données migrent là-dedans. Des algorithmes
crypto qui cryptent le train de données au côté de l'envoyeur et le décryptent
au côté du receveur. On y peut être sûr que personne ne peut facilement suivre
le train de données et même si quelqu'un va l'enregistrer pour l'analyser
postérieurement, on ne le peut pas déchiffrer dans un espace de temps vivable.
Donc on peut transmettre des données en texte clair sur une connexion
sanctuarisée – le chiffrage de la connexion les rend méconnaissable pour
l'extérieur pour que personne ne puisse y faire des bêtises.
On peut donc appliquer des procédés insécurisés, par exemple pour se connecter
à un ordinateur distant, par exemple Telnet même s'il est quelque chose qu'il
faut éviter si possible. Normalement il y a SSH comme remplacement qui est une
barrière presque insurmontable
si configuré proprement. On pourrait
considérer Telnet dans un tunnel IPsec d'être au moins aussi sécuritaire.
En outre on pourrait exporter un
NFS dans un tunnel IPsec
pour accéder auquel d'un autre ordinateur comme s'il serait un répertoire local.
On y peut s'épargner se connecter à un ordinateur distant, mais on a cependant
l'accès aux fichiers dans un répertoire exporté comme si on a se connecté là.