Zein aplikazio-trafiko eramaten du SSH birbidalketa batek benetan?

Terminala konektatu egiten da, gonbita agertzen da, eta denak ados daude SSH sarbidea funtzionatzen duela. Gero, ordenagailu eramangarriko datu-base bezero batek oraindik ezin du ostalari pribatura iritsi, eta saioari errua botatzen zaio. Eraiki zena maskor bat zen, eta hori SSHk eskain dezakeen lau interfaze oso desberdinetako bat da. Lehenengo aipa interfazea, eta gero egiaztatu aplikazioak benetan erabiltzen duela. Ordenak garrantzia du, interfaze bakoitzak bere erara huts egiten baitu.

Aipa interfazea ezer alderatu aurretik

OpenSSH bezeroaren eskuliburua lau mekanismo bereizten ditu, nahasteko errazak direnak. Maskor batek edo urruneko komando batek SSH ostalarian exekutatzen du. Tokiko birbidalketa batek entzuten duen socket bat irekitzen du bezeroan eta hurrengo konexioa urruneko aldetik egiten du. Urruneko birbidalketak alderantziz egiten du, zerbitzariaren aldean entzunez. Birbidalketa dinamikoak SOCKS amaiera-puntu bat erakusten du nola erabili dakiten programentzat.

• Maskorra: programa urruneko makinan exekutatzen da, ezerk ez du tokian entzuten.
• Tokiko birbidalketa: zure ordenagailuak ataka bat du, urruneko ostalariak irteerako konexioa egiten du.
• Urruneko birbidalketa: urruneko aldeak ataka bat du, trafikoa zuregana itzultzen da.
• Dinamikoa: SOCKS proxy bat bezeroan, proxyaz jabetzen diren aplikazioek soilik erabilia.

Horietako batek ere ez du ibilbiderik instalatzen. Proxy ezarpenak alde batera uzten dituen, edo UDP hitz egiten duen, edo izenak bere kabuz ebazten dituen programa, ez dio SSH saio aktibo batek eragiten. Hori ez da SSHren akats bat; aukeratu duzun interfazearen irismena da.

Tokiko, urruneko eta dinamiko birbidalketek entzuten duenaren arabera egiten dute desberdin

Kasurik gehienak erabakitzen dituen bereizketa entzuten duen socketaren jabea nor den da. Tokiko birbidalketan bezeroak entzuten du eta urruneko muturrak helmuga markatzen du, horregatik helburu helbidea zerbitzariaren ikuspuntutik ebazten da. Urruneko birbidalketan zerbitzariak entzuten du eta konexioa zure aldera eramaten da, eta horrela tokiko zerbitzu bat erakusten duzu zuzenean argitaratu gabe.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Lehen komandoak 5432 ataka lotzen du ordenagailuan eta datu-basera birbidaltzen du, bastioitik ikusten den moduan. Bigarrenak SOCKS proxy bat sortzen du 1080 atakan. Hirugarren komandoak zein prozesu entzuten ari diren egiaztatzen du, eta hori da birbidalketa existitzen dela frogatzeko froga bakarra, isilik ataka-gatazka baten ondorioz huts egin beharrean.

Birbidalketa dinamikoak bere abisua merezi du: SOCKS errespetatzen duten aplikazioak baino ez ditu estaltzen. Nabigatzaile bat bertara bidera daiteke, komando-lerroko tresna bati erabiltzeko esan dakioke, baina bere konexio-pila propioa duen datu-base kontrolatzaile batek normalean ezin du. Makinako programa guztiek tunela erabiltzen dutela suposatzea da arlo oso honetako akats ohikoena.

Tunel-gailu modua da benetako sare-salbuspen bakarra

OpenSSHk -w tunel-gailu birbidalketa ere onartzen du, TCP entzule bat beharrean puntutik punturako interfaze bat pasatzen duena. Hori benetako sare-tunel bat da, eta nahita konfiguratzen da, ez maskor bat irekitzearen bigarren efektu gisa.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Bi muturretan erabilgarri dauden interfaze-zenbaki egokiak behar ditu, zerbitzariko konfigurazio zuzena eta bezeroan gailua sortzeko nahikoa pribilegio. Helbideratze- eta bideratze-plan bat ere behar du, interfaze soil batek ez baitu erabakirik eramaten zein helburuk erabili beharko luketen.

Hala ere, tunela urruneko ostalarian amaitzen da. SSH garraioak eman zuen babesa han amaitzen da, eta hurrengo konexioa jauzi bereizia da. VPN ate batek muga-forma bera du, horregatik alderaketak irismenari eta amaierari buruzkoa izan behar du, eta ez zein tresna den indartsuena. Muga hori ozen aipatzeak tunel batek «dena zifratzen duen» ala ez eztabaida ere argitzen du, argi eta garbi ez baitu egiten.

Egiaztatu zure aplikazioak eraiki duzun interfazea erabiltzen duela

Egiaztapena aplikazioko da, ez saioko. Funtzionatzen duen birbidalketa batek ataka lotuta dagoela eta urruneko aldeak marka dezakeela frogatzen du; ez du frogatzen axola zaizun programak hortik konektatu duenik.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Lehen komandoak eskaera bat bidaltzen du SOCKS amaiera-puntutik, ostalari-izena urrunetik ebatzita, eta bigarrenak birbidalitako datu-base ataka erabiltzen du TLS oraindik derrigorrezkoa delarik. Exekutatu proba berdinak birbidalketa geldituta dagoela, huts egiten dutela ziurtatzeko, bi moduetara pasatzen den proba batek ez baitzuen inoiz tunela erabili.

Gero alderatu VPN bideratu batekin axola duten dimentsioetan soilik: zein helmuga estaltzen diren, zein protokolo funtzionatzen duten, non amaitzen den babesa eta nork onartu behar duen sarbidea. Zerbitzu bakarreko birbidalketa erantzun estuagoa eta hobea izan daiteke, eta VPN forma zuzena da aplikazio askok sare-bide bera behar dutenean. Biak ez dute beren urruneko amaiera-puntutik irisgarri den guztia ematen.