Kako ograničiti pristup između dvije kancelarije povezane VPN-om

Tunel između lokacija odgovara na jedno pitanje, mogu li dvije kancelarije razmjenjivati pakete, a ostavlja otvoreno ono važno: koji uređaj podružnice smije doći do koje centralne usluge. Tretiranje tunela kao uzajamnog povjerenja jeste način na koji gostujući laptop završi na istoj putanji kao finansijski server. Rješenje nije bolji tunel, nego izričit spisak dozvola koji se primjenjuje nakon dešifrovanja. Ovaj priručnik vodi taj spisak od definicije do dokazanog odbijanja.

Radite ovim redom i ne širite rutu tunela dok koraci politike ispod ne prođu.

Napišite matricu prije nego što dirnete u prolaz

Koristan red navodi tri stvari: grupu izvora, odredišni host ili servisnu mrežu, te protokol i port koji aplikacija zaista koristi. Podružnica i data centar nisu stavke. Privatni DNS i usluge autentifikacije zaslužuju vlastite redove samo kada aplikacija ne može raditi bez njih.

Grupirajte izvore po ulozi, a ne po pogodnosti podmreže: osoblje, gosti, administracija. Kada sva tri dijele jedan ravni LAN, prolaz ih ne može razlikovati na mrežnom sloju, pa kontrola identiteta ili segmentacija moraju doći prve. Zatim stavite matricu na papir, s vlasnikom i datumom pregleda u svakom redu.

Primijenite pravila tamo gdje se paketi dešifruju

Pravila koja dozvoljavaju IKE i ESP grade samo vanjski tunel. Unutrašnji saobraćaj stiže otvoren na interfejs tunela i tu pripada spisak dozvola: lanac prosljeđivanja na dešifrovanom uređaju, podrazumijevano odbacivanje, jedno pravilo po redu matrice. Na Linux prolazima to znači omogućeno prosljeđivanje i filter pravila na uređaju tunela, a ne na fizičkom uplinku, kako objašnjava strongSwan vodič za prosljeđivanje.

Selektori saobraćaja su odluka o rutiranju, a ne o autorizaciji. Širok selektor koji pokriva obje podmreže može biti ispravan za rutiranje dok firewall i dalje dozvoljava samo TCP 443 prema jednom hostu. Selektor se pregovara za tunel i opisuje šta smije ući u njega, a ne šta smije koristiti bilo koji uređaj. Nikada ne širite firewall pravilo zato što je selektor širok.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT i preklapajuće podmreže mijenjaju pravila

Kada prolaz podružnice prevede svaki host u jednu adresu prije tunela, svaki red zasnovan na izvoru pada u tu jednu adresu. Ili prestanite prevoditi saobraćaj tunela, ili prihvatite da pravila moraju počivati na nečem drugom, poput originalne izvorne adrese zabilježene prije prevođenja. Drugi kraj ima isti problem, jer odredišni host vidi adresu nakon NAT-a, a ne originalnu.

Preklapajući opsezi su druga zamka. Dvije kancelarije koje obje koriste 192.168.1.0/24 ne mogu se opisati u jednoj tabeli politike bez mapiranja jedne strane, a mapiranje nije zamjena za adresiranje koje se ne sudara. Popravite plan prije nego što napišete pravila koja ćete kasnije morati razmrsiti.

Dokažite odbijanje, a ne samo uspjeh

Testiranje samo dozvoljene aplikacije dokazuje vrlo malo, jer popustljivo pravilo negdje uzvodno daje isti rezultat.

S običnog uređaja u podružnici dođite do predviđene usluge i potvrdite da cijela sesija radi. Zatim pokušajte odredište koje mora ostati zatvoreno, poput administrativnog porta na serveru do kojeg podružnica nema posla, i pročitajte brojač ili zapis u dnevniku koji ga je odbacio. Isključivanje skupa pravila da provjerite radi li poništava test i ostavlja prolaz otvoren dok gledate.

Držite spisak živim

Aplikacije se sele, a pravilo koje nadživi svoju aplikaciju postaje rupa koju nitko ne posjeduje. Povežite datum pregleda s redom i promijenite obuhvat selektora i firewall pravilo u istom koraku održavanja kada usluga promijeni adresu.

Ograničenja na nivou hosta i dalje su važna iza tunela: vlastiti firewall servera treba prihvatati opseg podružnice samo za uslugu koju objavljuje. Dva sloja koja se slažu lakše je revidirati od jednog sloja kojem se slijepo vjeruje.