Išsaugokite vietinį SSH, kai serveris naudoja išeinančią VPN

Nedidelis Linux serveris naudoja išeinančią VPN programai, kurią talpina, o administratorius vis dar nori pasiekti jį per SSH iš gretimo stalelio. Tai pagrįstas reikalavimas, ir paprastai jam nereikia nei prievadų persiuntimo, nei tiekėjo adreso, nei skylės tunelyje. Ko reikia — tai sąmoningai suprojektuoto valdymo kelio, o ne paveldėto iš to, ką VPN klientas padarė maršrutų lentelei.

Toliau pateikti veiksmai daro prielaidą, kad administratorius yra tame pačiame LAN.Nuotolinis administravimas yra kita problema su kitu atsakymu.

Susiekite SSH su adresu, kurį naudoja administratoriai

Pradėkite nuo klausytojo.ss -ltnp | grep :22 rodo, prie ko sshd yra susietas, o klausytojas adresu 0.0.0.0 priima ryšius iš kiekvienos sąsajos, įskaitant tunelį. Susiejimas su LAN adresu yra siauresnis ir padaro ketinimą matomą:ListenAddress 192.168.10.20 failo sshd_config viduje, po to konfigūracijos testas ir perkrovimas. Rašybos klaida tame adrese labiau matoma nei pakaitos simbolis, nes sshd atsisako paleisti, kai adreso nėra.

Palikite pagrindinio kompiuterio rakto tikrinimą ir kiekvieno naudotojo autentifikavimą lygiai tokius, kokie jie yra. „Tai tik vietinis tinklas“ nėra autentifikavimo metodas, o valdymo kanalas, kuris praleidžia rakto tikrinimą dėl to, kad maršrutas trumpas, yra valdymo kanalas, laukiantis piktnaudžiavimo. DHCP rezervacija arba statinis adresas daro taikinį nuspėjamą, nepaverčiant jo viešuoju serverio tapatumu.

Išlaikykite LAN maršrutą už tunelio ribų

Serveris, kurio adresas yra 192.168.10.0/24, turi prijungtą maršrutą tam priešdėliui, o konkretesnis maršrutas nugali VPN numatytąjį toje pačioje lentelėje. Štai kodėl vietinis SSH dažnai veikia savaime, kai tunelis pakyla. Patikrinkite tai, o ne manykite:ip route get 192.168.10.50 nurodo sąsają ir šaltinio adresą, kuriuos naudotų branduolys, o atsakymas turėtų būti LAN įrenginys, ne tunelis. Pakartokite patikrinimą ir iš administratoriaus mašinos, nes jos pačios lentelė sprendžia, ar paketai kada nors atkeliaus. Du serveriai tame pačiame laide gali nesutarti, kuri kryptis pasiekiama.

Prielaida lūžta dviejose vietose. Politika pagrįsta maršrutizavimo taisyklė gali nusiųsti srautą į lentelę, kurios numatytasis rodo į tunelį, prieš tai, kai pasižiūrima į pagrindinę lentelę. VPN klientas su užrakinimo arba kill switch funkcija taip pat gali blokuoti srautą, kuris nepatenka į tunelį, neatsižvelgiant į tai, ką sako maršrutų lentelė.

Maršrutizuoti valdymo VLAN yra kitas atvejis. Jei administratorius sėdi 192.168.50.0/24 už vietinio maršrutizatoriaus, serveriui reikia aiškaus maršruto tam priešdėliui per 192.168.10.1, ir tas maršrutas turi išgyventi pakartotinį prisijungimą. Išimtį laikykite konkrečiai valdymo priešdėliui; plati išimtis privatiems diapazonams sugriauna tunelio tikslą.

Padarykite ugniasienės išimtį tokią siaurą kaip taisyklė

Jei serveris turi ugniasienę, leiskite SSH tik iš valdymo šaltinio ir tik LAN sąsajoje. Taisyklė, leidžianti 22 prievadą iš visur, yra platesnė už reikalavimą ir sunkiau pateisinama peržiūroje. nftables serveryje taisyklė priklauso įvesties grandinei su suderinta sąsaja ir šaltiniu; iptables serveryje atitikmuo yra pora atitikmenų -i ir -s. Komentuokite taisyklę administratorių grupe, kuriai ji tarnauja, kad kitas auditas neturėtų spėlioti, kodėl 22 prievadas atviras.

Patikrinkite ir paties VPN kliento filtrą. Kai kurie klientai įdiegia taisykles, kurios pagal dizainą numeta vietinį srautą, o teisinga ugniasienės taisyklė virš kliento lygio numetimo nieko nekeičia. Perskaitykite kliento konfigūraciją prieš redaguodami serverio ugniasienę, nes du filtrai iš eilės sukuria gedimą, nepanašų nė į vieną iš jų.

Išbandykite abi būsenas

Atlikite testą du kartus: vieną kartą su prijungtu tuneliu ir vieną kartą atjungtu. Kiekvienoje būsenoje patvirtinkite klausytoją, maršrutą ir tikrą SSH prisijungimą iš administratoriaus mašinos. Kelias, kuris veikia tik tol, kol tunelis pakeltas, nėra vietinis valdymo kelias; tai atsitiktinumas.

Tada iš naujo paleiskite tunelį, kol SSH sesija atidaryta. Sesija, kuri išlieka, įrodo, kad maršrutizavimas stabilus; sesija, kuri nutrūksta, pasako, kad klientas pakartotinio prisijungimo metu perrašo maršrutus arba filtrus, o tai verta žinoti prieš incidentą, o ne jo metu.

Užsirašykite šaltinio adresą, iš kurio testavote, nes taisyklė, parašyta 192.168.10.50, tyliai sugenda, kai administratoriaus nešiojamasis kompiuteris persikelia į kitą potinklį.

Įrašykite atkūrimo kelią į runbook

Nuspręskite dabar, kas nutiks, jei išeinanti VPN sugadins vietinį kelią. Prieiga per konsolę, antras valdymo adresas arba dokumentuota kliento sustabdymo procedūra yra visi teisėti atsakymai, ir bet kuris iš jų geriau nei atrasti problemą tuo metu, kai reikia prisijungti. Jei serveris yra nuotolinis, vietinio kelio nėra, o teisingas sprendimas yra atskiras patvirtintas nuotolinės prieigos maršrutas arba bastionas, o ne atviras viešas prievadas.

Laikykite du vaidmenis atskirai dokumentacijoje: vietinis SSH netoliese esančiam administratoriui ir išeinantis tunelis programos srautui. Kai tie vaidmenys užrašyti, būsimas bet kurio iš jų pakeitimas turi aiškią vietą patikrinimui, o kitas žmogus neturi iš naujo atrasti, kodėl serveris su VPN vis dar atsako savo LAN adresu.