Geen tun0? Pas ontsleutelde IPsec in nftables aan met die meta ipsec-uitdrukking

Jy verwag 'n tonnelkoppelvlak, jy soek een, en daar is niks in die vuurmuur om aan te pas nie. Dit is normaal vir 'n beleidsgebaseerde poort: die versleutelde uitruiling kom op die fisiese koppelvlak aan, en die ontsleutelde binneste pakket wat verder aangestuur word, word ook waargeneem asof dit op dieselfde koppelvlak aankom. Daar is geen tun0 nie, want niks het een geskep nie.

Die binneste versoek is steeds 'n afsonderlike pakket met sy eie bron, bestemming en diens, en die kern weet uit watter sekuriteitsassosiasie dit gekom het. Daardie kennis is wat 'n vuurmuurreël kan pas.

Twee pakkette, een koppelvlak

Stel jou die inkomende rigting voor. 'n ESP- of UDP-ingekapselde pakket kom aan, die kern vind die passende beleid, ontsleutel dit en gee die onversleutelde pakket aan die aanstuurpad. 'n Reël wat net na die koppelvlaknaam kyk, kan daardie pakket nie van enige ander verkeer wat op dieselfde draad aankom, onderskei nie.

Wat dit onderskei, is die inkomende sekuriteitspadkonteks wat aan die pakket geheg is. nftables stel dit bloot as meta ipsec exists, wat waar is wanneer die pakket deur 'n IPsec-sekuriteitspad aangekom het. Kombineer dit met die kliëntpoel, die bestemming en die diens, en die reël word spesifiek genoeg om veilig te wees.

Om die konteks weg te laat is die algemene fout, en dit is 'n sekuriteitsfout eerder as 'n kosmetiese een. 'n Reël wat enigiets uit die kliëntpoel aanvaar, aanvaar net so graag 'n vervalste pakket van die plaaslike netwerk, want die bronadres is op sigself geen bewys van enigiets nie. Die sekuriteitspadkonteks is die goedkoopste manier om die bron betekenisvol te maak. Skryf die reël van die begin af daarmee, eerder as om dit ná 'n oudit by te voeg.

Skryf die reël vir aansturing

Neem 'n geoutentiseerde IPv4-afstandtoegangdiens aan met kliënte in 10.90.0.0/24 en een goedgekeurde bestemming by 203.0.113.40. 'n Reëlfragment vir daardie vloei lyk soos volg.

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

Die adresse en koppelvlak is voorbeelde wat vervang moet word. Plaas die nagegane ekwivalent in die aanstuurbeleid voor die reël wat die vloei andersins sou verwerp, en moenie 'n bestaande reëlstel uitvee om dit te installeer nie; 'n poort is nie 'n skoonkamer-eksperiment nie.

Die oifname-term is die moeite werd om te hou. Dit dokumenteer die uitgaande besluit en verhoed dat die reël in 'n rigting pas wat jy nie bedoel het nie, wat saak maak op 'n poort met verskeie weë na die internet. Op 'n toetskas met een opvoerlyn lyk die term oorbodig, en dit is juis hoekom dit weggegooi word voordat die kas 'n tweede opvoerlyn kry.

Toestemmings vir die buitenste uitruiling is afsonderlik. Die poort se invoerpad het die IKE- en ESP- of UDP-inkapselingspoorte nodig wat dit werklik gebruik, en daardie toestemmings magtig niks aangaande die ontsleutelde pakket binne nie. Om die twee te vermeng, is hoe 'n werkende tonnel beland met 'n vuurmuur wat alles aanstuur.

Inkomende konteks is nie uitgaande konteks nie

Dieselfde familie uitdrukkings dek die ander rigting met rt ipsec, wat die uitgaande sekuriteitsassosiasie beskryf wat 'n pakket gaan gebruik. Dit beantwoord 'n ander vraag: nie waar hierdie pakket vandaan kom nie, maar of dit op sy volgende been beskerm sal word.

Daardie onderskeid maak saak op 'n poort wat een tonnel beide beëindig en in 'n ander aanstuur. 'n Pakket kan ontsleutel aankom en steeds versleutel moet vertrek, en 'n aanvaarding wat net vir die inkomende konteks geskryf is, sê niks oor die uitgaande vereiste nie. As die beleid daardie beskerming vereis, moet die reëlstel dit uitdruk eerder as om aan te neem die roetering sal dit hanteer.

Hou die twee vrae in afsonderlike reëls sodat 'n leser kan sien watter een afgedwing word. 'n Enkele slim reël wat albei nagaan, is moeiliker om na te gaan en baie moeiliker om te ontfout wanneer een helfte ophou pas. Twee reëls met tellers sê ook vir jou watter vereiste faal, wat een gekombineerde reël nooit sal doen nie.

NAT is nie 'n vuurmuurbesluit nie

Verkeer na die internet vanaf 'n private kliëntpoel het gewoonlik bronvertaling nodig sodat die antwoord sy weg terug kan vind. Maar verkeer wat vir 'n ander uitgaande IPsec-beleid gekies is, moet sy vereiste vrystelling behou, en om elke private bron te maskeer sonder om aan die volgende beskermingsbesluit te dink, breek dit.

'n Aanvaarding binne 'n NAT-ketting is ook nie 'n algemene toelating nie. NAT en filtering het verskillende take, en 'n NAT-ketting ondersoek nie elke latere pakket van 'n gevestigde vloei nie, en dit is juis hoekom om daarop te reken vir sekuriteit reëls oplewer wat in toetse werk en onder las faal.

Die omgekeerde is ook waar en verras mense: 'n aanvaarding ergens in een filterbasisketting dra geen gewig teen 'n latere verwerping in 'n ander toepaslike ketting nie. Orde en kettingomvang bepaal die uitkoms, nie die teenwoordigheid van 'n aanvaarding in die lêer nie.

Verifieer die presiese binneste diens

Toets die spesifieke bestemming en poort wat jy gemagtig het, van 'n werklike kliënt, en bevestig dat die antwoord terugkom. Toets dan iets wat jy nie gemagtig het nie en kyk dat dit nie werk nie, want 'n reël wat te breed is, slaag die eerste toets net so goed soos 'n korrekte een. 'n Versoek wat nooit die kliënt verlaat nie, is ook nie 'n vuurmuurresultaat nie, so lees die tellers om te sien of die pakket hoegenaamd geëvalueer is. Twee toetse en een tellerlesing sal jou meer vertel as 'n namiddag se lees van die reëlstel.

Die nftables-verwysing dokumenteer meta ipsec, rt ipsec en die rigting-spesifieke uitdrukkings, en dit is die plek om sintaksis teen jou geïnstalleerde weergawe na te gaan. En hou die omvang eksplisiet: dit is 'n IPv4-voorbeeld, dit sê niks oor IPv6 nie, en dit maak nie willekeurige openbare poortaanstuur deel van die VPN-diens nie.