Saglabājiet vietējo SSH, kad resursdators izmanto izejošo VPN

Neliels Linux serveris izmanto izejošu VPN lietojumprogrammai, ko tas mitina, un administrators joprojām vēlas tam piekļūt ar SSH no blakus esošā galda. Tā ir pamatota prasība, un parasti tai nav nepieciešama ne portu pāradresācija, ne pakalpojumu sniedzēja adrese, ne caurums tunelī. Nepieciešams ir pārvaldības ceļš, kas projektēts apzināti, nevis mantots no tā, ko VPN klients izdarīja ar maršrutēšanas tabulu.

Tālāk minētie soļi pieņem, ka administrators atrodas tajā pašā LAN.Attālināta administrēšana ir cita problēma ar citu atbildi.

Piesaistiet SSH adresei, ko izmanto administratori

Sāciet ar klausītāju.ss -ltnp | grep :22 parāda, kam sshd ir piesaistīts, un klausītājs uz 0.0.0.0 pieņem savienojumus no katras saskarnes, tostarp no tuneļa. Piesaiste LAN adresei ir šaurāka un padara nodomu redzamu:ListenAddress 192.168.10.20 failā sshd_config, kam seko konfigurācijas pārbaude un pārlāde. Ievadīšanas kļūda šajā adresē ir redzamāka nekā aizstājējzīme, jo sshd atsakās startēt, kad adreses nav.

Saglabājiet resursdatora atslēgas pārbaudi un autentifikāciju katram lietotājam tieši tādu, kāda tā ir. „Tas ir tikai vietējais tīkls“ nav autentifikācijas metode, un pārvaldības kanāls, kas izlaiž atslēgas pārbaudi tāpēc, ka maršruts ir īss, ir pārvaldības kanāls, kas gaida ļaunprātīgu izmantošanu. DHCP rezervācija vai statiska adrese padara mērķi paredzamu, nepārvēršot to servera publiskajā identitātē.

Turiet LAN maršrutu ārpus tuneļa

Resursdatoram ar adresi 192.168.10.0/24 ir savienots maršruts šim prefiksam, un konkrētāks maršruts pārspēj VPN noklusējuma maršrutu tajā pašā tabulā. Tāpēc vietējais SSH bieži turpina darboties pats no sevis, kad tunelis paceļas. Pārbaudiet to, nevis pieņemiet:ip route get 192.168.10.50 nosauc saskarni un avota adresi, ko izmantotu kodols, un atbildei jābūt LAN ierīcei, nevis tunelim. Atkārtojiet pārbaudi arī no administratora mašīnas, jo tās pašas tabula izlemj, vai paketes vispār nonāks. Divi resursdatori uz viena kabeļa var nevienoties par to, kurš virziens ir sasniedzams.

Pieņēmums lūst divās vietās. Uz politiku balstīts maršrutēšanas noteikums var nosūtīt trafiku uz tabulu, kuras noklusējums norāda tunelī, pirms tiek apskatīta galvenā tabula. VPN klients ar bloķēšanas vai kill switch funkciju var arī bloķēt trafiku, kas neietilpst tunelī, neatkarīgi no tā, ko saka maršrutēšanas tabula.

Maršrutēti pārvaldības VLAN ir otrs gadījums. Ja administrators atrodas 192.168.50.0/24 aiz vietējā maršrutētāja, serverim ir vajadzīgs skaidrs maršruts šim prefiksam caur 192.168.10.1, un šim maršrutam jāiztur atkārtots savienojums. Turiet izņēmumu specifisku pārvaldības prefiksam; plašs izņēmums privātajiem diapazoniem iznīcina tuneļa mērķi.

Padariet ugunsmūra izņēmumu tik šauru, cik noteikumu

Ja resursdators darbojas ar ugunsmūri, atļaujiet SSH tikai no pārvaldības avota un tikai LAN saskarnē. Noteikums, kas atļauj portu 22 no visur, ir plašāks par prasību un grūtāk attaisnojams pārbaudē. nftables resursdatorā noteikums pieder ievades ķēdei ar saskaņotu saskarni un avotu; iptables resursdatorā ekvivalents ir pāris atbilstību -i un -s. Komentējiet noteikumu ar administratoru grupu, kurai tas kalpo, lai nākamajai auditam nav jāmin, kāpēc ir atvērts ports 22.

Pārbaudiet arī paša VPN klienta filtru. Daži klienti instalē noteikumus, kas pēc dizaina izmet vietējo trafiku, un pareizs ugunsmūra noteikums virs klienta līmeņa izmešanas neko nemaina. Izlasiet klienta konfigurāciju pirms resursdatora ugunsmūra rediģēšanas, jo divi filtri pēc kārtas rada kļūmi, kas nav līdzīga nevienam no tiem.

Pārbaudiet abus stāvokļus

Veiciet testu divreiz: vienreiz ar pievienotu tuneli un vienreiz atvienotu. Katrā stāvoklī apstipriniet klausītāju, maršrutu un īstu SSH pieteikšanos no administratora mašīnas. Ceļš, kas darbojas tikai tad, kamēr tunelis ir augšā, nav vietējais pārvaldības ceļš; tas ir nejaušība.

Pēc tam restartējiet tuneli, kamēr SSH sesija ir atvērta. Sesija, kas iztur, pierāda, ka maršrutēšana ir stabila; sesija, kas pārtraucas, stāsta, ka klients atkārtotas savienošanas laikā pārraksta maršrutus vai filtrus, ko ir vērts zināt pirms incidenta, nevis tā laikā.

Pierakstiet avota adresi, no kuras testējāt, jo noteikums, kas rakstīts 192.168.10.50, klusi neizdodas, kad administratora portatīvais dators pārvietojas uz citu apakštīklu.

Ierakstiet atjaunošanas ceļu runbook

Izlemiet tagad, kas notiks, ja izejošais VPN salauzīs vietējo ceļu. Piekļuve konsolei, otra pārvaldības adrese vai dokumentēta procedūra klienta apturēšanai ir visas likumīgas atbildes, un jebkura no tām ir labāka par problēmas atklāšanu tajā brīdī, kad jums jāpiesakās. Ja serveris ir attālināts, vietējā ceļa nav, un pareizais risinājums ir atsevišķs apstiprināts attālinātās piekļuves maršruts vai bastions, nevis atklāts publisks ports.

Turiet abas lomas atsevišķi dokumentācijā: vietējais SSH tuvumā esošajam administratoram un izejošais tunelis lietojumprogrammas trafikam. Kad šīs lomas ir pierakstītas, turpmākām izmaiņām jebkurā no tām ir acīmredzama vieta pārbaudei, un nākamajam cilvēkam nav no jauna jāatklāj, kāpēc serveris ar VPN joprojām atbild uz tā LAN adresi.