SSH-bastion eller direkte VPN-tilgang: hvilken policy gjelder?
Utfør fire kontroller i rekkefølge: hva bastionen styrer, om målet kan skille veiene, hva loggene inneholder og hvor policyen håndheves.
Om VPN-brukere kan nå tjenere uten å krysse en sprettevert, er et policyspørsmål i nettverksklær. Hvis bastionen utfører en påkrevd kontroll, må det å koble seg til VPN føre til den og ikke rundt den. Hvis spretteverten bare broet et segment som før var utilgjengelig, kan en smal direkte vei være den ærlige erstatningen. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved den første som feiler, fordi det svaret avgjør resten.
Kontroller hva bastionen faktisk styrer
Begynn med bevis om nåtiden, ikke et diagram fra designdokumentet. Se på målets SSH-konfigurasjon og pakkefilter: hvis inngående port 22 bare godtas fra bastionens adresse, er spretteverten en håndhevet kontroll. Hvis samme port godtar tilkoblinger fra hele VPN-poolen, var bastionen en bekvemmelighet og håndhevingen bor helt andre steder. Sakshistorikken bekrefter vanligvis hvilken av de to som fantes først.
Formuler funnet i én setning som navngir kontrollen bastionen gir: destinasjonsbegrensning, et andre autentiseringstrinn, sesjonsopptak eller operativ synlighet under en hendelse. Det er den setningen erstatningspolicyen må bevare.
Kontroller om målet kan skille veiene
Regler for kildeadresse virker bare så lenge de to veiene ankommer med ulike kildeadresser. En VPN-gateway som maskerer trafikk til tjenernettet visker ut den forskjellen, og da ser hver tilkobling til port 22 ut som den kommer fra gatewayen. Kontrollen er lokal på målet og tar et øyeblikk: list de etablerte SSH-sesjonene og les peer-adressen for hver.
Når begge veiene faller sammen til én adresse, må forskjellen gjøres tidligere, ved hvilke destinasjoner VPN-et får skyve til og ved gatewayens egne filtre. Å legge til en regel på målet i den situasjonen skaper en illusjon av grense uten å endre det som ankommer.
Kontroller hva hver post faktisk inneholder
Tre ulike logger beskriver tre ulike hendelser, og ingen av dem erstatter en annen. VPN-ets tilkoblingspost viser at en identitet gikk inn i nettverksområdet. Bastionens videresendingspost viser en TCP-kanal som forlater den mot en destinasjon og port. Målets autentiseringslogg viser at en konto logget på over SSH. Det er å lese dem sammen som gir en tidslinje; å lese én alene gir en gjetning.
Ingen av disse postene inneholder hva som skjedde inne i den krypterte sesjonen mellom klient og mål. Hvis gjennomgang på kommandonivå er et krav, trengs en bevisst utrullet opptaksmekanisme med egne regler for datahåndtering. Å forvente det fra sprettevertens logger er måten et revisjonshull holder seg skjult på til det betyr noe.
Kontroller hvor policyen faktisk håndheves
En klientinnstilling som ProxyJump er en forespørsel, ikke en begrensning. OpenSSH åpner gjerne en direkte tilkobling når destinasjonen er tilgjengelig, så konfigurasjonsfiler på bærbare beskriver hensikt mens brannmurer avgjør resultatet. Håndhevingen hører til VPN-gatewayens tillatte destinasjoner og til målets egne tilgangsregler, og ingen av dem kan brukeren redigere. Revider samtidig de alternative veiene: et andre grensesnitt, en offentlig lytter, et mesh-lag eller en eldre nettsteds-til-nettsteds-tunnel kan hver gjenopprette snarveien du nettopp lukket.
Konfigurer ProxyJump likevel, fordi det gjør den godkjente ruten til den enkle og hindrer rutinearbeid i å lage unntak. Bekreft hva klienten faktisk løser opp før du stoler på den.
ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'
Bekreft med et bevisst direkte forsøk
En policy som aldri er testet, er et håp. Fra en klient tilkoblet VPN-et, forsøk veien som nå bør avvises, forsøk deretter den godkjente, og ta vare på begge resultatene. Det avviste forsøket er beviset på at endringen trådte i kraft.
nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true
Et rent resultat ser ut som en avvist eller tidsavbrutt direkte tilkobling til måladdressen, etterfulgt av en vellykket pålogging på spretteverten og en autentiseringspost på målsiden som navngir den støttede kilden. Alt annet betyr at grensen fortsatt er porøs, uansett hva dokumentasjonen sier. Noter datoen, regelen som ble endret og de to resultatene, og gi gjenopprettingsveien en eier og en utløpsdato slik at nødtilgang ikke stille blir den daglige ruten.