IPsec między dwoma hostami: gdzie ochrona się zaczyna, a gdzie kończy

Ochrona na parze hostów zaczyna się tam, gdzie kończy się asocjacja bezpieczeństwa, i jest to fakt, który najczęściej umyka intuicji ukształtowanej przez bramy. Serwer aplikacji i jego serwer bazy danych mogą chronić własną rozmowę bezpośrednio, bez żadnego koncentratora dostępu zdalnego na ścieżce, a granica ochrony leży wtedy w każdym hoście, a nie w zaporze ogniowej. Co to daje, to pokrycie od końca do końca dla wybranych przepływów. Czego to nie daje, to decyzji o tym, kto może czytać który wiersz.

Granica jest tam, gdzie kończy się SA

RFC 4301 opisuje asocjacje bezpieczeństwa w trybie transportowym jako układ zwykle używany między parą hostów do ochrony od końca do końca. Te dwa hosty trzymają klucze i każdy z nich decyduje, które z jego własnych pakietów wchodzą do asocjacji. Tunel bramy kończy się zupełnie gdzie indziej i dociera do hosta przez dodatkowy segment wewnętrzny, co jest inną granicą zaufania, nawet gdy pakiet jest szyfrowany przez większość drogi.

Host-do-hosta i tryb transportowy nie są jednak synonimami. Dwa hosty mogą równie poprawnie zbudować między sobą asocjację w trybie tunelowym, więc najpierw wybierz tryb, a potem opisz punkty końcowe. Zapisz oba w notatce projektowej obok adresów partnerów, bo recenzent, który zna tylko tryb, założy ten drugi.

SPD decyduje o ochronie, trasa decyduje o kierunku

Tablica routingu odpowiada na to, dokąd trafia pakiet. Baza polityki bezpieczeństwa odpowiada na to, jak wybrany ruch przekracza granicę ochrony, i robi to dla każdego kierunku z własnymi selektorami. Ten podział jest powodem, dla którego działająca trasa do bazy danych niczego nie dowodzi w kwestii tego, czy żądanie było chronione, i dlaczego ustanowione negocjacje niczego nie dowodzą w kwestii tego, czy ta konkretna aplikacja do nich pasowała. Porównaj selektory, zanim porównasz liczniki, bo liczniki opisują tylko te przepływy, które zaszły tak daleko.

W systemie Linux ip xfrm policy wypisuje te wpisy wraz z ich kierunkiem, priorytetem, selektorem i działaniem zezwól, blokuj lub przechwyć, podczas gdy ip xfrm state pokazuje wynikowe asocjacje i ich liczniki. Czytanie obu razem to sposób na znalezienie przepływu, który po cichu ominął tunel, ponieważ szerszy wpis zezwalający dopasował się pierwszy.

Kolejność priorytetów jest częścią polityki, a nie szczegółem implementacji. Wąski wpis, który powinien chronić port bazy danych, przegrywa z szerszym wpisem o wyższym priorytecie, a awaria wygląda tak, jakby polityka nigdy nie została zapytana.

Tryb transportowy obejmuje następną warstwę, a nie nagłówek IP

W trybie transportowym nagłówek ESP znajduje się między nagłówkiem IP a ładunkiem, a pola adresowe tego nagłówka pozostają widoczne dla każdego urządzenia na ścieżce. To w porządku, gdy adresy nie są tajemnicą, a ładunek jest. To zły wybór, jeśli trzeba także ukryć topologię wewnętrzną, bo tylko tryb tunelowy opakowuje oryginalny nagłówek w nowy.

Oba tryby mogą przenosić kilka protokołów następnej warstwy, a ESP ochroni to, co pasuje do selektora, a nie wszystko, co wysyła host.

Wybór jest węższy niż połączenie

Jedna asocjacja może przenosić wiele przepływów, ale tylko te, które wybiera polityka. Zanotuj tożsamości partnerów, adresy źródłowe i docelowe, protokół oraz zakres usługi dla zamierzonej relacji, a następnie osobno zdecyduj, czy niepasujący ruch może iść otwarcie, musi być chroniony, czy musi zostać odrzucony, gdy asocjacja jest niedostępna. Właśnie ta ostatnia decyzja powoduje niespodzianki, bo reguła wymagająca ochrony dla niewłaściwego źródła może zablokować własny dostęp administracyjny równie skutecznie, jak blokuje intruza.

Utrzymuj zatwierdzoną ścieżkę pozapasmową, zmieniając egzekwowanie, i przetestuj ją, zanim będzie potrzebna, a nie po tym, jak oba hosty staną się nieosiągalne.

Tożsamość maszyny nie jest uprawnieniem aplikacji

IPsec uwierzytelnia skonfigurowanego partnera i chroni wybrane pakiety. Nie decyduje, który rekord bazy danych osoba może edytować, i nie zamienia zaufanej tożsamości serwera w nadanie wszystkich uprawnień aplikacji. Konta aplikacji, role i autoryzacja pozostają dokładnie tam, gdzie były, a wymóg TLS na poziomie aplikacji zachowuje własny cel, nawet gdy ścieżka sieciowa jest już chroniona.

Przyjmij projekt z jedną operacją z zamierzonego źródła i jedną, która musi zostać odrzucona, i uwzględnij, co się dzieje, gdy wymaganej asocjacji nie da się ustanowić. Zwykły test osiągalności mówi, że pakiety się poruszają; nie mówi, że poruszały się zgodnie z polityką, którą napisałeś.