Nacrtajte dešifrirani put: gdje VPN uređaj provodi politiku

Dijagrami dobavljača obično staju na kriptiranom slušatelju, jer to je dio s javnom adresom. Pitanje koje određuje sigurnosni stav je što se događa nakon dešifriranja, kada paket postane običan IP i može dosegnuti sve što usmjerivačka tablica dopušta. Ako nitko nije nacrtao tu dionicu, nitko je ni ne posjeduje. Runbook ispod prvo je crta, a zatim uspoređuje smještaje po tome što dešifrirani zahtjev doista prelazi.

Nacrtajte paket nakon dešifriranja, ne prije

Vanjski put je dio koji dobavljači dokumentiraju: javna krajnja točka, transportna politika koja dopušta vezu i servis koji je terminira. Unutarnji put počinje u trenutku kada paket izgubi zaglavlje tunela, i odatle ga vode rute i pravila filtriranja koja nemaju veze s tunelom. Stavite oboje na istu stranicu, jer dijagram samo s prvim implicira da su prijem i autorizacija jedna odluka. Nisu, a jaz između njih je mjesto gdje većina smještaja pogriješi.

Napišite unutarnju dionicu kao numeriranu sekvencu s imenovanim tipovima uređaja, a ne kao strelicu. Strelica skriva prelazi li zahtjev filtar, a prelazak ili neprelazak je cijelo pitanje. Svaki korak ispod imenuje uređaj i skup pravila koji tamo djeluje, pa se filtar koji nedostaje pojavljuje kao praznina, a ne kao nešto što linija implicira.

1. Udaljeni klijent: korisnički uređaj koji stvara tunel.
2. Rubna politika: skup pravila koji dopušta vanjski transport do javnog slušatelja.
3. Terminirajući uređaj: VPN krajnja točka koja dekapsulira i predaje paket običnom IP-u.
4. Unutarnji filtar: skup pravila prosljeđivanja ili sigurnosnih grupa koji ograničava promet od klijenta do servisa.
5. Host aplikacije: servis koji prima dešifrirani zahtjev.

Dvije politike, dva vlasnika

Vanjska politika odgovara tko smije uspostaviti tunel i izražava se u pravilima koja dopuštaju transport do terminirajućeg servisa. Unutarnja politika odgovara do kojeg servisa autentificirani korisnik smije doći i živi u pravilima prosljeđivanja, sigurnosnim grupama ili u samoj aplikaciji. Jedan uređaj može ugostiti oboje, a dizajn s više uređaja i dalje ima oboje. Upravo njihovo odvojeno imenovanje omogućuje da kažete koja je zakazala kada korisnik ne može doći do aplikacije.

Kontrole prijema poput certifikata i višefaktorske autentifikacije odgovaraju na identitet i ništa drugo. One ne odlučuju o smještaju i ne daju dopuštenje po resursu kada je korisnik unutra.

Smještaj odlučuje koju granicu zahtjev prelazi

Tri su smještaja uobičajena i svaki mijenja koju granicu dešifrirani zahtjev prelazi. Usporedite ih po tome što tamo terminira, što može vidjeti čisti tekst, koja kontrola još može odbiti zahtjev i što pada zajedno s uređajem. Tablica ispod koristi ta četiri stupca umjesto općenitog pitanja, jer je svaki odgovor zasebna dizajnerska odluka.

Treći smještaj je onaj koji tiho uklanja provođenje, jer dionica na zaštićenom segmentu daje uređaju izravan put koji dijagram možda ne prikazuje. Pregledajte sučelja i rute, a ne sliku: ip route get 10.20.5.10 govori kroz koje sučelje bi paket izašao, a odgovor često nije onaj koji je dizajn pretpostavio. Klasična uloga vatrozida da kontrolira promet između postura, kako je opisano uNIST SP 800-41, koristan je test ovdje, jer uređaj s neograničenom dionicom prema zaštićenoj mreži ne kontrolira mnogo. Traženje rute iskreniji je dijagram od onog u prezentaciji.

Administracija pripada svom vlastitom izričito dopuštenom putu. Dopuštanje korisnicima da dođu do aplikacije nikada ne zahtijeva dopuštanje pristupa kontrolnom sučelju uređaja, a te dvije dozvole treba dodijeliti različitim pravilima. Provjerite oba puta odvojeno, jer zajedničko pravilo skriva koji je otvoren.

Prevođenje mijenja što nizvodna pravila mogu vidjeti

Prevođenje izvora je zgodno i uništava informacije. Nakon maskiranja svaki klijent izgleda kao uređaj, pa nizvodno pravilo napisano da razlikuje korisnike to više ne može. To nije samo problem zapisa, to je problem politike: pravilo vezano uz adresu klijenta tiho postaje pravilo vezano uz pristupnik. Ako je politika po korisniku važna, sačuvajte izvor ili primijenite politiku prije prevođenja.

Povratni put zaslužuje istu pažnju. Zabilježite koju rutu odredište bira za povratni paket, jer asimetričan povratak zaobilazi inspekciju stanja i stvara vezu koja se uspostavi i zatim zaglavi. Oba smjera moraju prijeći granicu koju ste nacrtali, inače je granica dekoracija.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Prihvatite dopuštenu i odbijenu operaciju

Testirajte s pravog udaljenog klijenta, a ne s administrativnog hosta, jer administrativni host obično stoji negdje gdje korisnik nikada neće biti. Jedna dopuštena operacija dokazuje da put radi, a jedna odbijena dokazuje da politika uopće nešto radi. Pokrenite obje nakon svake promjene smještaja i zabilježite identitet izvora i odredište koje ste koristili. Test koji dokazuje samo uspjeh ne može razlikovati ispravno pravilo od onog koje nedostaje.

Zatim testirajte slučajeve koji mijenjaju stanje: ponovno povezivanje, sesiju koja nadživi rotaciju ključa i otkaz samog uređaja. Usporedite ažuriranja, kapacitet i oporavak kao dio istog rasporeda, jer jedan uređaj koji drži nekoliko logičkih kontrola jedna je domena otkaza s nekoliko oznaka. Ni drugi uređaj nije neovisan kada zajednička administrativna vjerodajnica ili neograničena ruta pobijedi granicu koju je trebao stvoriti.

Dokumentirajte krajnju točku, dešifrirani put i kontrolu koja ga ograničava. Ta tri retka ostaju smislena kako god se implementacija zvala.