Skysikkerheitsgruppe for ein VPN: opne lyttaren, ikkje alt

VPN-tenaren køyrer, klienten får tidsavbrot, og den første impulsen er å leggje til ein regel som tillèt alt i sikkerheitsgruppa. Det får det nokre gonger til å verke, og det er det verste utfallet, for no veit ingen kva grense som faktisk vart lukka. Fire separate filter står mellom klienten og daemonen, og berre eitt av dei er sikkerheitsgruppa.

Nemne protokollen før regelen

Ein regel er ein protokoll, eit portområde og ei kjelde. WireGuard lyttar på UDP, vanlegvis 51820. OpenVPN er vanlegvis UDP eller TCP 1194 avhengig av konfigurasjonen. IPsec treng IKE-utvekslinga på UDP 500 og 4500 pluss sjølve ESP-protokollen, som er eit protokollnummer og ikkje ein port. Å gjette TCP fordi dei andre reglane er TCP er korleis ein endar med ein regel som ser rett ut og ikkje treff noko.

Les lyttaren frå den køyrande tenesta, ikkje frå ei rettleiding. Ein daemon bunden til éi adresse godtek ikkje trafikk som kjem inn på ei anna.

Avgrens kjelda til klientområdet designet tillèt, i staden for heile internett.

Sikkerheitsgrupper er tilstandsfulle; subnett-ACL-ar er det ikkje

Sikkerheitsgrupper er tilstandsfulle og berre tillètande: ein tillaten inngåande flyt får svara sine automatisk, og det finst ingen avvisingregel å tenkje på. Subnett-ACL-ar er tilstandslause og vert vurderte i begge retningar, så ei inngåande tillating utan det samsvarande utgåande efemere området feilar framleis. Den skilnaden forklarer mange reglar som ser rette ut i konsollen.

Stadfest òg kva policy som er knytt til det køyrande endepunktet, sidan ein instans kan ha meir enn éi gruppe, og ein regel i ei ikkje-tilknytt gruppe endrar ingenting.

Den effektive policyen er sameininga av det som er tilknytt, ikkje fila du redigerte.

Vertsbrannmuren er ei eiga grense

Skypolicyen slepp trafikk til nettverksgrensesnittet, og deretter avgjer operativsystemet om daemonen ser han. Ein vertsbrannmur med standard avvisingspolicy vil sleppe ein pakke som sikkerheitsgruppa tillét, og skykonsollen viser inga avvising fordi han aldri hadde ei meining. Kontroller begge, i den rekkjefølgja pakken møter dei.

Viss verten brukar ein brannmur-frontend frå distribusjonen, stadfest dei underliggjande reglane i staden for profilnamnet, fordi ein profil kan vere aktiv medan porten er stengd.

Eit opptak på grensesnittet fortel deg kva grense som sleppte pakken.

Å tillate lyttaren er ikkje å rute klientane

Ein VPN-gateway som vidaresender klienttrafikk treng meir enn ein open port. Han treng IP-vidaresending, ein policy som tillèt flyten frå tunnelgrensesnittet til målnettverket, og ofte ein kjelde-mål-sjekk som er slått av på grensesnittet slik at plattforma ikkje kastar trafikk som ikkje er adressert til henne. Ingenting av dette vert skapt av lyttarregelen.

Det er her eit fungerande handtrykk og ein øydelagd datasti skil lag, og difor kan ein tunnelstatus sjå sunn ut medan ingenting lastar.

Rett rutinga som ei eiga endring med si eiga verifisering, og merk at ein vidaresendande gateway òg treng ein utgangspolicy som tillèt målet.

Hald ein veg tilbake, og snevra deretter inn regelen

Før du endrar ekstern brannmurpolicy, stadfest at det finst ein uavhengig administrasjonsveg, som ein sesjonshandsamar, ein seriell konsoll eller eit nettverk utanfor bandet. Viss den einaste administrasjonsvegen går gjennom regelen du redigerer, har du inga gjenoppretting. Bruk deretter den smale regelen, test frå ein ekte klient, og korreler forsøket med bevis på tenarsida. Eit svar frå ei anna teneste på same maskin er ikkje bevis for at lyttaren vart nådd.

Fjern kvar eksperimentell brei tillating så snart den smale verkar, og noter kvifor regelen finst. AWS dokumenterer den tilstandsfulle åtferda til sikkerheitsgrupper, og det dokumentet er det ein skal sitere når nokon føreslår eit breitt område som ei snarveg.

Dokumenter tilknytinga òg, elles vil eit erstatningsgrensesnitt miste policyen lydlaust.