No hi ha tun0? Feu coincidir l'IPsec desxifrat a nftables amb meta ipsec

Espereu una interfície de túnel, la busqueu i no hi ha res a la tallafoc amb què fer-la coincidir. Això és normal en una passarel·la basada en polítiques: l'intercanvi xifrat arriba a la interfície física, i el paquet intern desxifrat que després es reenvia també s'observa com si arribés a aquesta mateixa interfície. No hi ha tun0 perquè res no l'ha creat.

La petició interna continua sent un paquet diferent amb el seu origen, destinació i servei, i el nucli sap de quina associació de seguretat ha sortit. Aquest coneixement és el que una regla de tallafoc pot fer coincidir.

Dos paquets, una interfície

Imagineu la direcció d'entrada. Arriba un paquet encapsulat en ESP o UDP, el nucli troba la política corresponent, el desxifra i lliura el paquet clar al camí de reenviament. Una regla que només mira el nom de la interfície no pot distingir aquest paquet de qualsevol altre trànsit que arribi pel mateix cable.

El que el distingeix és el context del camí de seguretat d'entrada adjunt al paquet. nftables l'exposa com a meta ipsec exists, que és cert quan el paquet ha arribat per un camí de seguretat IPsec. Combineu-lo amb el conjunt de clients, la destinació i el servei, i la regla esdevé prou específica per ser segura.

Ometre el context és l'error habitual, i és un error de seguretat, no estètic. Una regla que accepta qualsevol cosa provinent del conjunt de clients accepta igual de gust un paquet falsificat de la xarxa local, perquè l'adreça d'origen no és prova de res per si mateixa. El context del camí de seguretat és la manera més barata de fer que l'origen signifiqui alguna cosa. Escriviu la regla amb ell des del principi en lloc d'afegir-lo després d'una auditoria.

Escriviu la regla de reenviament

Suposeu un servei d'accés remot IPv4 autenticat amb clients a 10.90.0.0/24 i una destinació aprovada a 203.0.113.40. Un fragment de regla per a aquest flux té aquest aspecte.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Les adreces i la interfície són exemples que cal substituir. Col·loqueu l'equivalent revisat a la política de reenviament abans de la regla que d'altra manera rebutjaria el flux, i no buideu un conjunt de regles existent per instal·lar-lo; una passarel·la no és un experiment de cambra blanca.

Val la pena conservar el terme oifname. Documenta la decisió de sortida i evita que la regla coincideixi en una direcció que no volíeu, cosa que importa en una passarel·la amb diversos camins a internet. En una caixa de proves amb un sol enllaç ascendent el terme sembla redundant, i és exactament per això que es descarta abans que la caixa obtingui un segon enllaç.

Els permisos per a l'intercanvi exterior són a part. El camí d'entrada de la passarel·la necessita els ports IKE i ESP o d'encapsulació UDP que realment utilitza, i aquests permisos no autoritzen res sobre el paquet desxifrat de dins. Barrejar les dues coses és com un túnel funcionant acaba amb una tallafoc que reenvia tot.

El context d'entrada no és el context de sortida

La mateixa família d'expressions cobreix l'altra direcció amb rt ipsec, que descriu l'associació de seguretat de sortida que utilitzarà un paquet. Respon una altra pregunta: no d'on ve aquest paquet, sinó si estarà protegit en el seu següent tram.

Aquesta distinció importa en una passarel·la que alhora acaba un túnel i reenvia cap a un altre. Un paquet pot arribar desxifrat i tot i així haver de sortir xifrat, i una acceptació escrita només per al context d'entrada no diu res sobre el requisit de sortida. Si la política exigeix aquesta protecció, el conjunt de regles ha d'expressar-ho en lloc de suposar que l'encaminament se n'encarregarà.

Manteniu les dues preguntes en regles separades perquè el lector pugui veure quina s'aplica. Una sola regla enginyosa que comprova totes dues és més difícil de revisar i molt més difícil de depurar quan una meitat deixa de coincidir. Dues regles amb comptadors també us diuen quin requisit falla, cosa que una regla combinada mai no farà.

NAT no és una decisió de tallafoc

El trànsit cap a internet des d'un conjunt de clients privat normalment necessita traducció d'origen perquè la resposta trobi el camí de tornada. Però el trànsit seleccionat per a una altra política IPsec de sortida ha de mantenir l'exempció necessària, i emmascarar cada origen privat sense pensar en la següent decisió de protecció ho trenca.

Una acceptació dins d'una cadena NAT tampoc no és un permís general. NAT i filtratge tenen feines diferents, i una cadena NAT no examina cada paquet posterior d'un flux establert, i és exactament per això que confiar-hi per a la seguretat produeix regles que semblen funcionar en proves i fallen sota càrrega.

El contrari també és cert i sorprèn la gent: una acceptació en algun lloc d'una cadena base de filtratge no té cap pes contra un rebuig posterior en una altra cadena aplicable. L'ordre i l'abast de la cadena decideixen el resultat, no la presència d'una acceptació al fitxer.

Verifiqueu el servei intern exacte

Proveu la destinació i el port concrets que heu autoritzat, des d'un client real, i confirmeu que la resposta torna. Després proveu una cosa que no heu autoritzat i comproveu que no passa, perquè una regla massa àmplia supera la primera prova igual de bé que una de correcta. Una petició que mai no surt del client tampoc no és un resultat de tallafoc, així que llegiu els comptadors per veure si el paquet s'ha avaluat. Dues proves i una lectura de comptador us diran més que tota una tarda llegint el conjunt de regles.

La referència de nftables documenta meta ipsec, rt ipsec i les expressions específiques de direcció, i és el lloc on comprovar la sintaxi amb la versió instal·lada. I manteniu l'abast explícit: això és un exemple IPv4, no diu res sobre IPv6 i no converteix el reenviament arbitrari de ports públics en part del servei VPN.