SSH bastion o direktang VPN access: aling patakaran ang nalalapat?

Kung makakaabot ang mga gumagamit ng VPN sa mga server nang hindi dumadaan sa jump host ay tanong ng patakaran na nakasuot ng damit ng network. Kung nagsasagawa ang bastion ng kinakailangang kontrol, ang pagsali sa VPN ay dapat tumungo rito at hindi lumibot dito. Kung pinagdurugtong lamang ng jump host ang isang bahagi na dating hindi maabot, ang makitid na direktang landas ay maaaring maging tapat na kapalit. Gawin ang mga pagsusuri sa ibaba nang sunud-sunod at huminto sa unang bigong pagsusuri, dahil ang sagot na iyon ang magpapasya sa iba.

Suriin kung ano ang aktwal na kinokontrol ng bastion

Magsimula sa ebidensiya tungkol sa kasalukuyan, hindi sa diagram mula sa dokumento ng disenyo. Tingnan ang SSH configuration at packet filter ng target: kung ang papasok na port 22 ay tinatanggap lamang mula sa address ng bastion, ang jump host ay sapilitang kontrol. Kung ang parehong port ay tumatanggap ng mga koneksyon mula sa buong pool ng VPN, ang bastion ay kaginhawahan lamang at ang pagpapatupad ay nasa ibang lugar nang lubos. Karaniwang kinukumpirma ng history ng ticket kung alin sa dalawa ang nauna.

Sabihin ang natuklasan sa isang pangungusap na nagbibigay ng pangalan sa kontrol na ibinibigay ng bastion: paghihigpit sa destinasyon, ikalawang hakbang ng pagpapatunay, pag-record ng sesyon, o operasyonal na kakayahang makita habang may insidente. Iyon ang pangungusap na dapat pangalagaan ng kapalit na patakaran.

Suriin kung nakikilala ng target ang mga landas

Gumagana lamang ang mga tuntunin ng source address habang dumarating ang dalawang landas na may magkaibang source address. Binubura ng VPN gateway na nagma-mask ng trapiko patungo sa subnet ng server ang pagkakaibang iyon, at pagkatapos ay mukhang galing sa gateway ang bawat koneksyon sa port 22. Lokal ang pagsusuri sa target at tumatagal ng isang sandali: ilista ang mga naitatag na sesyon ng SSH at basahin ang address ng kapares para sa bawat isa.

Kapag nagbagsak ang dalawang landas sa isang address, dapat gawin ang pagkakaiba nang mas maaga, sa pamamagitan ng mga destinasyong pinapayagang itulak ng VPN at ng sariling filter ng gateway. Ang pagdaragdag ng tuntunin sa target sa ganoong sitwasyon ay lumilikha ng ilusyon ng hangganan nang hindi binabago ang dumarating.

Suriin kung ano ang aktwal na hawak ng bawat tala

Tatlong magkaibang log ang naglalarawan ng tatlong magkaibang pangyayari, at wala sa kanila ang pumapalit sa isa. Ipinapakita ng connection record ng VPN na may pagkakakilanlan na pumasok sa saklaw ng network. Ipinapakita ng forwarding record ng bastion ang isang TCP channel na lumalabas mula rito patungo sa destinasyon at port. Ipinapakita ng authentication log ng target na may account na nag-sign in sa SSH. Ang pagbasa sa kanila nang sama-sama ang gumagawa ng timeline; ang pagbasa ng isa lamang ay gumagawa ng haka-haka.

Wala sa mga talang iyon ang naglalaman ng nangyari sa loob ng naka-encrypt na sesyon sa pagitan ng client at target. Kung kailangan ang pagsusuri sa antas ng command, kailangan nito ng mekanismong pang-record na sadyang inilagay na may sariling mga tuntunin sa paghawak ng datos. Ang umasa nito sa mga log ng jump host ay ang paraan na nananatiling nakatago ang puwang sa audit hanggang sa maging mahalaga ito.

Suriin kung saan aktwal na ipinatutupad ang patakaran

Ang setting ng client tulad ng ProxyJump ay kahilingan, hindi paghihigpit. Buong galak na magbubukas ang OpenSSH ng direktang koneksyon kapag maabot ang destinasyon, kaya inilalarawan ng mga configuration file sa laptop ang layunin habang ang firewall ang nagpapasya sa resulta. Ang pagpapatupad ay kabilang sa mga pinapayagang destinasyon ng VPN gateway at sa sariling mga tuntunin ng pag-access ng target, at hindi mababago ng gumagamit ang alinman. Suriin din nang sabay ang mga alternatibong landas: ang ikalawang interface, pampublikong listener, mesh layer o lumang site-to-site tunnel ay maaaring bawat isa ay magbalik ng shortcut na kauuwi lang ng pagsasara.

I-configure pa rin ang ProxyJump, dahil ginagawa nitong madali ang aprubadong ruta at pinipigilan ang rutinang trabaho na gumawa ng mga eksepsiyon. Kumpirmahin kung ano ang aktwal na nireresolba ng client bago ito pagkatiwalaan.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

I-verify gamit ang sadyang direktang pagtatangka

Ang patakarang hindi kailanman nasubok ay pag-asa. Mula sa client na konektado sa VPN, subukan ang landas na dapat tanggihan ngayon, pagkatapos subukan ang aprubado, at itago ang parehong resulta. Ang tinanggihang pagtatangka ang ebidensiyang nagkabisa ang pagbabago.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Ang malinis na resulta ay mukhang direktang koneksyon na tinanggihan o na-time out patungo sa address ng target, na sinusundan ng matagumpay na pag-log in sa jump host at ng entry ng authentication sa panig ng target na nagpapangalan sa sinusuportahang pinagmulan. Anumang iba ay nangangahulugang butas-butas pa rin ang hangganan, anuman ang sabihin ng dokumentasyon. Itala ang petsa, ang binagong tuntunin at ang dalawang resulta, pagkatapos bigyan ng may-ari at petsa ng pag-expire ang landas ng pagbawi upang ang emergency access ay hindi tahimik na maging pang-araw-araw na ruta.