IPsec între două gazde: unde începe și unde se oprește protecția
O pereche de gazde poate proteja fluxuri selectate fără o poartă. Definiți capetele, politica ce selectează traficul și permisiunile care rămân separate.
Protecția pe o pereche de gazde începe acolo unde se termină asociația de securitate, și acesta este faptul pe care intuiția modelată de porți îl ratează cel mai des. Un server de aplicații și serverul său de baze de date își pot proteja propria conversație direct, fără niciun concentrator de acces la distanță pe cale, iar granița de protecție se află atunci în interiorul fiecărei gazde și nu într-un paravan de protecție. Ce vă aduce este acoperire de la un capăt la altul pentru fluxuri selectate. Ce nu vă aduce este o decizie despre cine poate citi ce rând.
Granița este acolo unde se termină SA
RFC 4301 descrie asociațiile de securitate în modul transport ca aranjamentul folosit de obicei între o pereche de gazde pentru protecție de la un capăt la altul. Aceste două gazde dețin cheile, iar fiecare decide care dintre propriile pachete intră în asociație. Un tunel de poartă se termină cu totul în altă parte și ajunge la gazdă printr-un segment intern suplimentar, ceea ce este o altă graniță de încredere chiar și atunci când pachetul este criptat pe cea mai mare parte a drumului.
Gazdă-la-gazdă și modul transport nu sunt totuși sinonime. Două gazde pot construi la fel de corect o asociație în modul tunel între ele, așa că alegeți mai întâi modul și apoi descrieți capetele. Scrieți ambele în nota de proiectare lângă adresele perechilor, pentru că un recenzent care cunoaște doar modul îl va presupune pe celălalt.
SPD decide protecția, ruta decide direcția
Un tabel de rutare răspunde la întrebarea unde merge un pachet. Baza de date a politicii de securitate răspunde la întrebarea cum traversează traficul selectat granița de protecție, și o face pentru fiecare direcție cu propriii selectori. Această separare este motivul pentru care o rută funcțională către baza de date nu dovedește nimic despre dacă cererea a fost protejată, și motivul pentru care o negociere stabilită nu dovedește nimic despre dacă această aplicație anume i-a corespuns. Comparați selectorii înainte de a compara contoarele, fiindcă contoarele descriu doar fluxurile care au ajuns atât de departe.
Pe Linux, ip xfrm policy afișează acele intrări cu direcția, prioritatea, selectorul și acțiunea lor de permitere, blocare sau capturare, în timp ce ip xfrm state arată asociațiile rezultate și contoarele lor. Citirea celor două împreună este felul în care găsiți fluxul care a ocolit tunelul în liniște pentru că o intrare de permisiune mai largă s-a potrivit prima.
Ordinea priorităților face parte din politică, nu este un detaliu de implementare. O intrare îngustă care ar trebui să protejeze portul bazei de date pierde în fața unei intrări mai largi cu prioritate mai mare, iar eșecul arată ca și cum politica nu a fost niciodată consultată.
Modul transport acoperă stratul următor, nu antetul IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
În modul transport antetul ESP stă între antetul IP și sarcina utilă, iar câmpurile de adresă ale acelui antet rămân vizibile pentru fiecare dispozitiv de pe cale. Acest lucru este în regulă când adresele nu sunt secretul, iar sarcina utilă este. Este alegerea greșită dacă trebuie să ascundeți și topologia internă, pentru că doar modul tunel împachetează antetul original într-unul nou.
Ambele moduri pot transporta mai multe protocoale ale stratului următor, iar ESP va proteja ceea ce se potrivește cu selectorul, nu tot ce trimite gazda.
Selecția este mai îngustă decât conexiunea
O singură asociație poate transporta mai multe fluxuri, dar numai pe cele pe care politica le selectează. Înregistrați identitățile perechilor, adresele sursă și destinație, protocolul și sfera serviciului pentru relația pe care o intenționați, apoi decideți separat dacă traficul care nu se potrivește poate merge în clar, trebuie protejat sau trebuie aruncat atunci când asociația nu este disponibilă. Acea ultimă decizie este cea care produce surprize, pentru că o regulă care cere protecție pentru sursa greșită poate bloca propriul dumneavoastră acces de administrare la fel de eficient pe cât blochează un intrus.
Mențineți o cale în afara benzii aprobată în timp ce schimbați aplicarea, și testați-o înainte de a avea nevoie de ea, nu după ce ambele gazde devin inaccesibile.
Identitatea mașinii nu este o permisiune a aplicației
IPsec autentifică o pereche configurată și protejează pachetele selectate. Nu decide ce înregistrare din baza de date poate edita o persoană și nu transformă o identitate de server de încredere într-o acordare a tuturor privilegiilor aplicației. Conturile, rolurile și autorizarea aplicației rămân exact acolo unde erau, iar o cerință TLS la nivel de aplicație își păstrează propriul scop chiar și atunci când calea de rețea este deja protejată.
Acceptați proiectul cu o operație din sursa prevăzută și una care trebuie refuzată, și includeți ce se întâmplă când asociația necesară nu poate fi stabilită. Un test obișnuit de accesibilitate vă spune că pachetele se mișcă; nu vă spune că s-au mișcat sub politica pe care ați scris-o.