IPsec két hoszt között: hol kezdődik és hol ér véget a védelem

A hosztpáron a védelem ott kezdődik, ahol a biztonsági társítás véget ér, és éppen ezt a tényt szokta a leginkább elvéteni az átjárókra szabott intuíció. Egy alkalmazásszerver és az adatbázisszervere közvetlenül védheti a saját beszélgetését, anélkül hogy távoli hozzáférési koncentrátor lenne az útvonalon, és a védelmi határ ekkor az egyes hosztokon belül van, nem pedig egy tűzfalban. Amit ez ad, az a végpontok közötti lefedettség kiválasztott folyamatokra. Amit nem ad, az a döntés arról, ki melyik sort olvashatja.

A határ ott van, ahol az SA véget ér

Az RFC 4301 a szállítási módú biztonsági társításokat úgy írja le, mint a hosztpár között végpontok közötti védelemre tipikusan használt elrendezést. Ez a két hoszt tartja a kulcsokat, és mindegyik eldönti, hogy a saját csomagjai közül melyek lépnek be a társításba. Az átjárótunnel egészen máshol ér véget, és egy további belső szegmensen keresztül éri el a hosztot, ami más bizalmi határ, még akkor is, ha a csomag az útja nagy részében titkosított.

A hoszt-hoszt és a szállítási mód azonban nem szinonimák. Két hoszt ugyanilyen helyesen építhet egymás között alagút módú társítást, tehát először válassza ki a módot, és utána írja le a végpontokat. Mindkettőt jegyezze fel a tervezési feljegyzésbe a partnerek címei mellé, mert az a bíráló, aki csak a módot ismeri, a másikat fogja feltételezni.

Az SPD dönt a védelemről, az útvonal az irányról

Az útválasztási tábla arra válaszol, hová megy egy csomag. A biztonsági szabályzat adatbázisa arra válaszol, hogyan lép át a kiválasztott forgalom a védelmi határon, és ezt irányonként teszi, saját szelektorokkal. Ez a szétválasztás az oka annak, hogy egy működő útvonal az adatbázishoz semmit nem bizonyít arról, védett volt-e a kérés, és annak is, hogy egy létrejött egyeztetés semmit nem bizonyít arról, hogy ez a konkrét alkalmazás megfelelt-e neki. A szelektorokat hasonlítsa össze, mielőtt a számlálókat hasonlítja, mert a számlálók csak azokat a folyamatokat írják le, amelyek idáig eljutottak.

Linuxon a ip xfrm policy azokat a bejegyzéseket írja ki irányukkal, prioritásukkal, szelektorukkal és engedélyezés, tiltás vagy csapda műveletükkel, míg a ip xfrm state az eredményül kapott társításokat és azok számlálóit mutatja. A kettő együttes olvasása az a mód, ahogy megtalálja azt a folyamatot, amely csendben megkerülte az alagutat, mert egy szélesebb engedélyező bejegyzés előbb illeszkedett.

A prioritási sorrend a szabályzat része, nem megvalósítási részlet. Egy szűk bejegyzés, amelynek az adatbázis portját kellene védenie, kikap egy nagyobb prioritású szélesebb bejegyzéssel szemben, és a hiba úgy néz ki, mintha a szabályzatot soha nem kérdezték volna meg.

A szállítási mód a következő réteget fedi le, nem az IP-fejlécet

Szállítási módban az ESP-fejléc az IP-fejléc és a hasznos teher között helyezkedik el, és ennek a fejlécnek a címmezői láthatók maradnak az útvonal minden eszköze számára. Ez rendben van, ha a címek nem titkosak, a hasznos teher pedig igen. Rossz választás, ha a belső topológiát is el kell rejtenie, mert csak az alagút mód csomagolja az eredeti fejlécet egy újba.

Mindkét mód hordozhat több következő rétegbeli protokollt, és az ESP azt védi, amire a szelektor illeszkedik, nem mindent, amit a hoszt küld.

A kiválasztás szűkebb, mint a kapcsolat

Egyetlen társítás több folyamatot hordozhat, de csak azokat, amelyeket a szabályzat kiválaszt. Rögzítse a partnerek identitását, a forrás- és célcímeket, a protokollt és a tervezett kapcsolat szolgáltatási körét, majd külön döntse el, hogy a nem illeszkedő forgalom mehet-e nyíltan, védeni kell-e, vagy eldobandó-e, amikor a társítás nem elérhető. Az utolsó döntés az, amely meglepetéseket okoz, mert a rossz forráshoz védelmet előíró szabály éppolyan hatékonyan blokkolhatja a saját kezelési hozzáférését, mint ahogy egy betolakodót blokkol.

Tartson fenn jóváhagyott sávon kívüli útvonalat, miközben a kényszerítést változtatja, és tesztelje még azelőtt, hogy szüksége lenne rá, nem pedig azután, hogy mindkét hoszt elérhetetlenné vált.

A gép identitása nem alkalmazási engedély

Az IPsec hitelesíti a beállított partnert és védi a kiválasztott csomagokat. Nem dönti el, hogy egy személy melyik adatbázisrekordot szerkesztheti, és nem változtatja a megbízható kiszolgálóidentitást minden alkalmazási jogosultság megadásává. Az alkalmazásfiókok, a szerepkörök és az engedélyezés pontosan ott maradnak, ahol voltak, és az alkalmazásszintű TLS-követelmény megtartja a saját célját akkor is, ha a hálózati útvonal már védett.

Fogadja el a tervet egy művelettel a szándékolt forrásból és egy elutasítandóval, és foglalja bele, mi történik, ha a szükséges társítás nem hozható létre. Egy közönséges elérhetőségi teszt megmondja, hogy a csomagok mozognak; nem mondja meg, hogy az Ön által írt szabályzat alatt mozogtak.