IPsec entre dos equips: on comença i on acaba la protecció
Una parella d’equips pot protegir fluxos seleccionats sense cap passarel·la. Definiu els extrems, la política que selecciona el tràfic i els permisos que queden separats.
La protecció en una parella d’equips comença on acaba l’associació de seguretat, i aquest és el fet que la intuïció forjada per les passarel·les passa per alt més sovint. Un servidor d’aplicacions i el seu servidor de bases de dades poden protegir la seva pròpia conversa directament, sense cap concentrador d’accés remot al camí, i aleshores el límit de protecció se situa dins de cada equip en lloc d’un tallafocs. El que això us aporta és cobertura d’extrem a extrem per a fluxos seleccionats. El que no us aporta és una decisió sobre qui pot llegir quina fila.
El límit és on acaba l’SA
El RFC 4301 descriu les associacions de seguretat en mode transport com la disposició que normalment s’utilitza entre una parella d’equips per a la protecció d’extrem a extrem. Aquests dos equips tenen les claus, i cadascun decideix quins dels seus propis paquets entren a l’associació. Un túnel de passarel·la acaba en un lloc completament diferent i arriba a l’equip a través d’un segment intern addicional, que és un límit de confiança diferent fins i tot quan el paquet va xifrat durant la major part del seu recorregut.
Equip a equip i mode transport no són sinònims, però. Dos equips poden construir igual de correctament una associació en mode túnel entre ells, així que trieu primer el mode i després descriviu els extrems. Escriviu tots dos a la nota de disseny al costat de les adreces dels parells, perquè un revisor que només conegui el mode suposarà l’altre.
L’SPD decideix la protecció, la ruta decideix la direcció
Una taula d’encaminament respon on va un paquet. La base de dades de política de seguretat respon com travessa el tràfic seleccionat el límit de protecció, i ho fa per direcció amb els seus propis selectors. Aquesta separació és la raó per la qual una ruta que funciona cap a la base de dades no demostra res sobre si la petició estava protegida, i per la qual una negociació establerta no demostra res sobre si aquesta aplicació concreta hi va coincidir. Compareu els selectors abans de comparar els comptadors, ja que els comptadors només descriuen els fluxos que van arribar tan lluny.
A Linux, ip xfrm policy imprimeix aquestes entrades amb la seva direcció, prioritat, selector i acció de permetre, bloquejar o atrapar, mentre que ip xfrm state mostra les associacions resultants i els seus comptadors. Llegir les dues coses juntes és com trobeu el flux que va evitar el túnel en silenci perquè una entrada de permetre més àmplia hi va coincidir primer.
L’ordenació per prioritat forma part de la política, no és un detall d’implementació. Una entrada estreta que hauria de protegir el port de la base de dades perd davant d’una entrada més àmplia amb prioritat més alta, i el fracàs sembla indicar que la política no es va consultar mai.
El mode transport cobreix la capa següent, no la capçalera 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, la capçalera ESP se situa entre la capçalera IP i la càrrega útil, i els camps d’adreça d’aquesta capçalera continuen visibles per a tots els dispositius del camí. Això està bé quan les adreces no són el secret i la càrrega útil sí. És l’elecció equivocada si també heu d’amagar la topologia interna, perquè només el mode túnel embolcalla la capçalera original dins d’una de nova.
Tots dos modes poden portar diversos protocols de la capa següent, i l’ESP protegirà allò que coincideixi amb el selector en lloc de tot el que envia l’equip.
La selecció és més estreta que la connexió
Una sola associació pot portar diversos fluxos, però només aquells que la política selecciona. Registreu les identitats dels parells, les adreces d’origen i destinació, el protocol i l’abast del servei de la relació que voleu, i després decidiu per separat si el tràfic que no coincideix pot anar en clar, s’ha de protegir o s’ha de descartar quan l’associació no estigui disponible. Aquesta darrera decisió és la que produeix sorpreses, perquè una regla que exigeix protecció per a l’origen equivocat pot bloquejar el vostre propi accés de gestió amb la mateixa eficàcia que bloqueja un intrús.
Manteniu un camí fora de banda aprovat mentre canvieu l’aplicació, i proveu-lo abans de necessitar-lo en lloc de després que tots dos equips quedin inabastables.
La identitat de la màquina no és el permís de l’aplicació
L’IPsec autentica un parell configurat i protegeix els paquets seleccionats. No decideix quin registre de la base de dades pot editar una persona, i no converteix una identitat de servidor de confiança en una concessió de tots els privilegis de l’aplicació. Els comptes, els rols i l’autorització de l’aplicació es queden exactament on eren, i un requisit de TLS a nivell d’aplicació conserva el seu propi propòsit fins i tot quan el camí de xarxa ja està protegit.
Accepteu el disseny amb una operació des de l’origen previst i una que s’ha de refusar, i incloeu què passa quan l’associació requerida no es pot establir. Una prova d’abastabilitat corrent us diu que els paquets es mouen; no us diu que es moguessin sota la política que vau escriure.