IPsec entre deux hôtes : où la protection commence et où elle s’arrête
Une paire d’hôtes peut protéger des flux choisis sans passerelle. Définissez les extrémités, la politique qui sélectionne le trafic et les autorisations qui restent distinctes.
La protection sur une paire d’hôtes commence là où l’association de sécurité se termine, et c’est précisément le fait que l’intuition façonnée par les passerelles manque le plus souvent. Un serveur d’applications et son serveur de base de données peuvent protéger leur propre conversation directement, sans aucun concentrateur d’accès distant sur le chemin, et la frontière de protection se situe alors à l’intérieur de chaque hôte plutôt que dans un pare-feu. Ce que cela vous apporte, c’est une couverture de bout en bout pour des flux choisis. Ce que cela ne vous apporte pas, c’est une décision sur qui peut lire quelle ligne.
La frontière se situe là où se termine l’AS
La RFC 4301 décrit les associations de sécurité en mode transport comme l’arrangement habituellement utilisé entre deux hôtes pour une protection de bout en bout. Ces deux hôtes détiennent les clés, et chacun décide lesquels de ses propres paquets entrent dans l’association. Un tunnel de passerelle se termine ailleurs, complètement, et atteint l’hôte par un segment interne supplémentaire, ce qui constitue une autre frontière de confiance même lorsque le paquet est chiffré pendant la majeure partie de son trajet.
Hôte à hôte et mode transport ne sont pourtant pas synonymes. Deux hôtes peuvent tout aussi correctement construire entre eux une association en mode tunnel, alors choisissez d’abord le mode et décrivez ensuite les extrémités. Écrivez les deux dans la note de conception à côté des adresses des pairs, car un relecteur qui ne connaît que le mode supposera l’autre.
La SPD décide de la protection, la route décide de la direction
Une table de routage répond à la question de savoir où va un paquet. La base de données de politique de sécurité répond à la question de savoir comment le trafic sélectionné franchit la frontière de protection, et elle le fait par direction avec ses propres sélecteurs. Cette séparation explique pourquoi une route fonctionnelle vers la base de données ne prouve rien sur le fait que la requête était protégée, et pourquoi une négociation établie ne prouve rien sur le fait que cette application précise y correspondait. Comparez les sélecteurs avant de comparer les compteurs, car les compteurs ne décrivent que les flux qui sont allés jusque-là.
Sous Linux, ip xfrm policy affiche ces entrées avec leur direction, leur priorité, leur sélecteur et leur action allow, block ou trap, tandis que ip xfrm state montre les associations résultantes et leurs compteurs. Lire les deux ensemble est la façon de trouver le flux qui a contourné le tunnel en silence parce qu’une entrée allow plus large correspondait en premier.
L’ordre de priorité fait partie de la politique, ce n’est pas un détail d’implémentation. Une entrée étroite qui devrait protéger le port de la base de données perd face à une entrée plus large de priorité supérieure, et la défaillance donne l’impression que la politique n’a jamais été consultée.
Le mode transport couvre la couche suivante, pas l’en-tête IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
En mode transport, l’en-tête ESP se place entre l’en-tête IP et la charge utile, et les champs d’adresse de cet en-tête restent visibles pour tout équipement sur le chemin. C’est très bien quand les adresses ne sont pas le secret et que la charge utile l’est. C’est le mauvais choix si vous devez aussi masquer la topologie interne, car seul le mode tunnel enveloppe l’en-tête d’origine dans un nouvel en-tête.
Les deux modes peuvent transporter plusieurs protocoles de la couche suivante, et l’ESP protégera ce que le sélecteur retient plutôt que tout ce que l’hôte envoie.
La sélection est plus étroite que la connexion
Une seule association peut transporter plusieurs flux, mais seulement ceux que la politique sélectionne. Consignez les identités des pairs, les adresses source et destination, le protocole et la portée de service de la relation que vous envisagez, puis décidez séparément si le trafic non correspondant peut passer en clair, doit être protégé ou doit être abandonné lorsque l’association n’est pas disponible. C’est cette dernière décision qui produit des surprises, car une règle exigeant la protection pour la mauvaise source peut bloquer votre propre accès d’administration aussi efficacement qu’elle bloque un intrus.
Gardez un chemin hors bande approuvé pendant que vous modifiez l’application, et testez-le avant d’en avoir besoin plutôt qu’après que les deux hôtes sont devenus injoignables.
L’identité de la machine n’est pas une autorisation d’application
IPsec authentifie un pair configuré et protège les paquets sélectionnés. Il ne décide pas quel enregistrement de base de données une personne peut modifier, et il ne transforme pas une identité de serveur de confiance en octroi de tous les privilèges applicatifs. Les comptes, les rôles et l’autorisation de l’application restent exactement là où ils étaient, et une exigence TLS au niveau applicatif conserve sa propre finalité même lorsque le chemin réseau est déjà protégé.
Acceptez la conception avec une opération depuis la source prévue et une qui doit être refusée, et incluez ce qui se passe lorsque l’association requise ne peut pas être établie. Un test d’accessibilité ordinaire vous dit que les paquets circulent ; il ne vous dit pas qu’ils ont circulé sous la politique que vous avez écrite.