VPN bidez soilik eskuragarri dagoen HTTPS gune batera iristea SSH birbidalketa baten bidez
Konektatu VPN bidez soilik erabilgarri den HTTPS zerbitzu bat SSH birbidalketa lokal batekin, mantendu benetako ostalari-izena --connect-to aukerarekin, eta jakin zer ez duen TCP birbidalketa bakar batek estaltzen.
Makina batek badu jada onartutako VPN sarbidea, bigarren makina batek HTTPS zerbitzu pribatu bat behar du zehazki, eta SSH birbidalketa lokal batek hutsune hori zubitu dezake bigarren makinari tunel bat eman gabe. Birbidalketak TCP helmuga bakarra garraiatzen du sare osoaren ordez, eta muga hori da kontua. Jarraitu beheko bost urratsak ordenan, bakoitzak arrazoi desberdinagatik huts egiten duelako eta geroagoko urrats batek ezin duelako aurreko hutsunea salbatu. Baldintzaren bat falta bada, diseinu honek ez du konpontzen eta ez du komandoen doikuntzak lagunduko.
Lehen urratsa: egiaztatu hiru baldintzak
Hiru gauza egia izan behar dira edozein komandok garrantzia izan baino lehen. Lehen makina birbidalketa-ostalari gisa erabiltzeko baimena, hara SSH sarbide eraginkorra eta helmuga aurreikusitakoa onartzen duen zerbitzari-politika behar dituzu. Fitxategi-transferentziarako sortutako SSH kontuak birbidalketa desgaituta izan dezake, eta birbidalketa onartzen duen zerbitzariak oraindik mugatu dezake zein helmuga diren hara iristeko modukoak. Galdetu probatu aurretik, lankide baten lan-estazioa jauzi-puntu gisa akordiorik gabe erabiltzea politika-arazoa delako, komandoa garbi funtzionatzen duenean ere.
Bi komandok argitzen dute zerrenda horren erdi teknikoa. Lehenak frogatzen du kontuak eta gakoak elkarrekintzarik gabeko eskaerarik gabe funtzionatzen dutela, eta bigarrenak zerbitzariaren benetako politika inprimatzen du, konfigurazio-fitxategiko adibide iruzkinduaren ordez.
ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'
Bigarren urratsa: lotu loopback ataka bat eta mantendu saioa bizirik
Bezero-aplikazioa exekutatzen duen makinan, ireki birbidalketa lokal bat zerbitzu pribatura. Lotu espresuki loopback-era, sare lokalean argitaratu ez dadin, eta aukeratu inongo zerbitzu lokalek hartzen ez duen ataka altu bat. Mantendu saioa martxan lanean ari zaren bitartean, hura ixteak entzulea ixten baitu. ExitOnForwardFailure-ek ukatutako lotura edo okupatutako ataka irteera berehalako bihurtzen du, birbidalketarik gabe zutik geratzen den saio baten ordez, eta hori da denbora gehien alferrik galtzen duen hutsegite modua.
Konexio pribatua jauzi-ostalaritik egiten da, beraz haren DNS, ibilbide, VPN politika eta zerbitzu-sarbideak funtzionatu behar dute guztiek. SSH saioak ez du sortzen jauzi-ostalariak falta duen irisgarritasuna, eta ezin du konpondu VPNak inoiz bultzatu ez zuen ibilbide bat. Egiaztatu entzulea benetan dagoen lekuan, komandoaren isiltasunean fidatu beharrean.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'
Hirugarren urratsa: mantendu HTTPS izena socket-a lokala denean
https://127.0.0.1:9443/ arakatzeak TLS zerbitzari-izena eta aplikazioaren autoritatea aldatzen ditu. portal.lab.example-rako jaulkitako ziurtagiriak ez du loopback helbidearen aurka baliozkotuko, eta ondoriozko erroreak ziurtagiri hautsi bat dirudi, birbidalketa-aztarna baten ordez. Komando-lerroko proba baterako, mantendu benetako URLa eta aldatu socket-aren helmuga soilik. Hori egiten du --connect-to-ek, eta curl eskuliburuak behean erabiltzen den lau eremuko forma dokumentatzen du.
curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/
Izena URLan, TLS esku-ukaldian eta Host goiburuan geratzen da, TCP konexioa entzule lokalera doan bitartean. Proxyrik gabeko aukerak proba birbidalketa honetan mantentzen du, konfiguratutako HTTP proxy batek atzeman ez dezan, eta ziurtagiri-egiaztapena piztuta mantentzea da emaitza esanguratsu egiten duena.
Laugarren urratsa: jakin zer ez duen birbidalketa bakar batek estaltzen
TCP birbidalketa bakar batek helmuga-ataka bat estaltzen du. Bigarren ostalari-izen batera birbideratzen duen, sare pribatuaren barruko ostalari batetik baliabideak kargatzen dituen edo beste ataka batera bidaltzen duen orrialdeak bere birbidalketa propioa behar du, eta horietako bakoitzak lehenengoaren politika-egiaztapen bera behar du. Nabigatzailearen lan-fluxuek beren baldintzak gehitzen dituzte, nabigatzaileari esan behar baitzaio benetako izena ataka lokalera bidaltzeko proxy konfigurazioaren edo mapatze lokal baten bidez. Beraz, komando-lerroko proba arrakastatsu batek ez du frogatzen nabigatzaileak lortuko duenik, bidea frogatzen badu ere.
UDP, SMB aurkikuntza eta domeinu-hasiera ez dira inola ere TCP birbidalketa baten bidez ibiltzen. Benetako beharra sare-sarbide orokorra bada, diseinu hau tresna okerra da eta onartutako urrutiko sarbide-pasabidea da zuzena.
Bosgarren urratsa: garbitu eta erregistratu
Gelditu saioa proba amaitutakoan eta egiaztatu entzulea joan dela. Aukeratutako ataka okupatuta bazegoen, aukeratu erabili gabeko loopback ataka bat eta eguneratu batera URLa, proba-komandoa eta oharra, zenbakia askatzeko zerikusia ez duen zerbitzu lokal bat gelditu beharrean. Eramangarri batean birbidalketa irekita uzteak diagnostiko bat zerbitzu kudeagabe bihurtzen du.
Idatzi jauzi-ostalaria, birbidalitako helmuga, ataka lokala eta akordioa norbaitek onartu zuen. Norbaiten shell historialan soilik existitzen den birbidalketa berrabiarazte bat dago errepikatutako ikerketa batetik, eta hurrengo pertsonak ez daki hiru baldintzetatik zein egiaztatu den jada.