Un selector IPsec ampli no és permís per a cada servei

Dues parts acorden protegir tota una subxarxa, i algú llegeix aquest acord com un permís per arribar a cada servei que hi ha a dins. Aquest és el mite: el selector diu quin trànsit el túnel està disposat a transportar i no diu res sobre quins serveis permet l’organització. Un parell de dispositius poden negociar legítimament un rang d’adreces ampli mentre la política d’accés de dins permet dos ports, i les dues afirmacions continuen sent certes alhora.

La cobertura protegida no és autorització

Un selector de trànsit forma part de l’acord del túnel. Estreny o confirma què xifraran les parts entre elles, i un selector ampli sovint és la manera més senzilla d’operar quan els dos costats han de transportar molts fluxos. El filtre de serveis és un altre control en un altre punt del camí, i decideix què es pot fer servir realment un cop el paquet s’ha desxifrat. Treure el filtre perquè passi una prova converteix una decisió de política en un accident.

Manteniu els dos registres separats al document de disseny, perquè un lector que només veu el selector inferirà una autorització que no es va concedir mai. Dues línies en un registre de canvis ho eviten i triguen menys que la discussió que ve després.

Descriviu un flux des de les dues bandes

Anoteu l’iniciador, el responedor, l’origen i la destinació tal com es presenten, el protocol i tots dos ports. Després invertiu cadascuna d’aquestes etiquetes per a l’altre extrem, perquè el port d’origen efímer d’un client es converteix en el port de destinació d’una resposta i la xarxa remota passa a ser la local. Una configuració copiada d’un costat a l’altre sense aquesta inversió és com els filtres acaben permetent exactament la direcció equivocada. Escriviu la taula una vegada i construïu tots dos filtres a partir d’ella.

Acordeu el model de selecció abans de copiar res, perquè un disseny basat en polítiques i un disseny basat en rutes expressen la mateixa intenció amb objectes diferents. Escriviu el nom del model al costat del flux, o el proper enginyer passarà una tarda aparellant objectes que mai no van ser comparables.

Trobeu el filtre que realment s’aplica

En un ASA, el filtre VPN és una ACL associada a una política de grup i aplicada al trànsit després de desxifrar i abans de xifrar. La documentació de polítiques de grup de Cisco també descriu l’herència, incloent-hi un valor a nivell d’usuari que substitueix el valor de la política de grup. Per tant, l’ACL que heu editat pot no ser l’ACL que governa la sessió que teniu al davant. El mateix passa amb l’objecte d’usuari, que pot prevaldre sobre el grup sense deixar gaire rastre visible.

Inspeccioneu la sessió efectiva en lloc de l’objecte que recordeu haver canviat, i anoteu quin objecte de política la proporciona. Aquest sol pas resol una quantitat sorprenent d’informes del tipus el filtre és correcte però no funciona.

Direcció, ports i el cas invers

La convenció documentada situa la xarxa remota, o les adreces assignades dels clients remots, en la posició d’origen i la xarxa local en la posició de destinació, amb les respostes expressades intercanviant les posicions de les adreces. Les regles de ports se superposen a aquesta convenció i mereixen més cura que les adreces.

El model documentat pot permetre que una regla de port de destinació afecti una iniciació inversa que fa servir aquell mateix port d’origen, cosa que vol dir que el filtre no és simplement una regla de petició unidireccional amb respostes innòcues adjuntes. Penseu explícitament en totes dues direccions d’iniciació i incloeu el cas que voleu denegar.

La mateixa documentació limita el filtre a les connexions inicials, així que no és l’aplicació universal de cada canal secundari que obre una aplicació inspeccionada. Quan la política completa necessita aquesta cobertura, pertany a una frontera separada i no a una ACL estirada més enllà del seu propòsit.

Proveu tres casos abans de donar-ho per fet

Accepteu el flux previst, refuseu un servei que la política prohibeix i exerciteu el cas de direcció inversa que heu raonat. Executeu-los sota un pla aprovat amb les mateixes identitats i selectors que desplegareu. Una prova que només mostra que el servei permès funciona demostra el túnel, no la política.

Manteniu la cobertura negociada i la decisió d’accés com a dos registres, perquè explicar què permet una VPN requereix tots dos.