IPsec tussen twee hosts: waar beskerming begin en eindig

Beskerming op ’n hostpaar begin waar die sekuriteitsassosiasie eindig, en dit is die feit wat die meeste poortgerigte intuïsie miskyk. ’n Toepassingbediener en sy databasisbediener kan hulle eie gesprek direk beskerm, met geen afstandtoegang-konsentrator in die pad nie, en die beskermingsgrens lê dan binne elke host eerder as in ’n vuurmuur. Wat dit vir jou koop, is end-tot-end-dekking vir gekose vloei. Wat dit nie vir jou koop nie, is ’n besluit oor wie watter ry mag lees.

Die grens is waar die SA eindig

RFC 4301 beskryf transportmodus-sekuriteitsassosiasies as die reëling wat tipies tussen ’n paar hosts vir end-tot-end-beskerming gebruik word. Daardie twee hosts hou die sleutels, en elkeen besluit watter van sy eie pakkette die assosiasie binnegaan. ’n Poorttonnel eindig heeltemal elders en bereik die host deur ’n bykomende interne segment, wat ’n ander vertrouensgrens is selfs wanneer die pakket vir die grootste deel van sy reis geënkripteer is.

Host-tot-host en transportmodus is egter nie sinonieme nie. Twee hosts kan net so korrek ’n tonnelmodus-assosiasie tussen hulle bou, so kies eers die modus en beskryf dan die eindpunte. Skryf albei in die ontwerpnota langs die eweknie-adresse, want ’n resensent wat net die modus ken, sal die ander een aanneem.

Die SPD besluit oor beskerming, die roete besluit oor rigting

’n Roetertabel antwoord waar ’n pakket heen gaan. Die sekuriteitsbeleid-databasis antwoord hoe die gekose verkeer die beskermingsgrens oorsteek, en dit doen dit per rigting met sy eie keurders. Daardie skeiding is die rede waarom ’n werkende roete na die databasis niks bewys oor of die versoek beskerm is nie, en waarom ’n gevestigde onderhandeling niks bewys oor of hierdie spesifieke toepassing daarby gepas het. Vergelyk die keurders voordat jy die tellers vergelyk, want die tellers beskryf net die vloei wat so ver gekom het.

Op Linux, ip xfrm policy druk daardie inskrywings uit met hulle rigting, prioriteit, keurder en aksie van toelaat, blokkeer of lok, terwyl ip xfrm state die resulterende assosiasies en hulle tellers wys. Om die twee saam te lees, is hoe jy die vloei vind wat die tonnel stilweg omseil het omdat ’n breër toelaat-inskrywing eerste gepas het.

Prioriteitsordening is deel van die beleid, nie ’n implementeringsdetail nie. ’n Smal inskrywing wat die databasispoort behoort te beskerm, verloor teen ’n breër inskrywing met hoër prioriteit, en die fout lyk of die beleid nooit geraadpleeg is nie.

Transportmodus dek die volgende laag, nie die IP-opskrif nie

In transportmodus sit die ESP-opskrif tussen die IP-opskrif en die ladingsinhoud, en die adresvelde van daardie opskrif bly sigbaar vir elke toestel op die pad. Dit is goed wanneer die adresse nie die geheim is nie en die lading wel. Dit is die verkeerde keuse as jy ook die interne topologie moet versteek, want net tonnelmodus wikkel die oorspronklike opskrif in ’n nuwe een in.

Albei modusse kan verskeie volgende-laag-protokolle dra, en ESP beskerm wat die keurder pas eerder as alles wat die host stuur.

Keuring is smaller as die verbinding

’n Enkele assosiasie kan verskeie vloei dra, maar net dié wat die beleid keur. Teken die eweknie-identiteite, die bron- en bestemmingsadresse, die protokol en die diensomvang van die verhouding wat jy beoog aan, en besluit dan apart of nie-passende verkeer in die oopte mag gaan, beskerm moet word, of laat val moet word wanneer die assosiasie onbeskikbaar is. Daardie laaste besluit is die een wat verrassings lewer, want ’n reël wat beskerming vir die verkeerde bron vereis, kan jou eie bestuurstoegang net so doeltreffend blokkeer as wat dit ’n indringer blokkeer.

Hou ’n goedgekeurde buiteband-pad terwyl jy die handhawing verander, en toets dit voordat jy dit nodig het eerder as nadat albei hosts onbereikbaar geword het.

Masjienidentiteit is nie toepassingstoestemming nie

IPsec verifieer ’n opgestelde eweknie en beskerm gekose pakkette. Dit besluit nie watter databasisrekord ’n persoon mag redigeer nie, en dit verander nie ’n vertroude bedieneridentiteit in ’n toestemming vir elke toepassingsvoorreg nie. Toepassingrekeninge, rolle en magtiging bly presies waar hulle was, en ’n TLS-vereiste op toepassingsvlak behou sy eie doel selfs wanneer die netwerkpad reeds beskerm is.

Aanvaar die ontwerp met een bewerking vanaf die bedoelde bron en een wat geweier moet word, en sluit in wat gebeur wanneer die vereiste assosiasie nie gevestig kan word nie. ’n Gewone bereikbaarheidstoets sê vir jou dat pakkette beweeg; dit sê nie vir jou dat hulle onder die beleid beweeg het wat jy geskryf het nie.