Trimiterea a tot către serverul VPN poate descrie două reguli foarte diferite. Una schimbă adresa de destinație și păstrează portul de intrare; cealaltă rescrie și portul către un singur ascultător. Expunerea nu este aceeași, iar decizia depinde de trei condiții, nu de eticheta folosită de interfața routerului.

Prima condiție: ce câmpuri modifică regula?

Traducerea adresei de destinație și traducerea portului de destinație sunt operațiuni separate. O regulă poate executa doar prima sau ambele împreună, iar diferența decide ce servicii de pe gazda țintă sunt accesibile. Majoritatea interfețelor producătorilor ascund această alegere în spatele unei singure etichete. Citirea regulii de bază este singura modalitate de a ști pe care ați obținut-o.

Citiți regula reală, nu eticheta meniului. Un ecran care spune DMZ sau toate porturile descrie o intenție, nu o cale a pachetelor. Documentația Netfilter NAT separă cele două traduceri, iar acesta este modelul mental corect chiar și atunci când routerul din fața dumneavoastră este un aparat de consum.

Două câmpuri, două întrebări diferite.

A doua condiție: ce ascultă pe porturile păstrate?

Dacă regula păstrează portul de intrare, fiecare port care sosește este livrat aceluiași număr de pe gazda VPN, în funcție de politica de intrare a acelei gazde. Aceasta include servicii despre care poate ați uitat că ascultau. Regula nu a creat acele servicii, iar acum ea este calea către ele.

Dacă regula rescrie portul, se întâmplă invers: multe porturi externe se prăbușesc pe un singur ascultător, iar nimic altceva de pe gazdă nu este accesibil prin acea regulă. O rescriere pe un port fix nu devine acces la fiecare serviciu local doar pentru că un interval larg de porturi externe s-a potrivit pe ea. Cele două modele eșuează în direcții diferite, iar modul de eșec este ceea ce alegeți. Alegeți-l pe cel cu al cărui eșec puteți trăi.

Inventariați ascultătorul înainte de a alege.

A treia condiție: cât de largă este intrarea externă?

Publicarea unui singur port ales este mai îngustă decât publicarea unui interval, iar ambele sunt mai înguste decât acceptarea tuturor. Lățimea externă și traducerea internă sunt alegeri independente, iar cea mai mare parte a confuziei provine din schimbarea uneia în timp ce o descrieți pe cealaltă.

Pentru o intrare VPN obișnuită, publicați transportul și ascultătorul de care proiectul are nevoie cu adevărat. Apoi verificați încă trei lucruri: maparea efectivă a routerului, regulile de intrare proprii ale gazdei țintă și dacă un ascultător IPv6 publică același serviciu. O regulă care pare îngustă într-o familie de adrese poate fi largă în cealaltă.

Scrieți punctul final tradus în întregime: protocol, port extern, adresă internă, port intern.

Ce nu vă oferă niciuna dintre reguli

Niciunul dintre cele două modele nu dovedește că serviciul este lipsit de vulnerabilități și niciunul nu protejează disponibilitatea. Autentificarea, actualizările și recuperarea rămân în scop indiferent cât de îngustă este maparea porturilor. O mapare îngustă reduce suprafața accesibilă; nu face ascultătorul sigur.

O regulă largă care deja susține un alt serviciu legitim este o dependență, nu doar o greșeală. Inventariați-o și înlocuiți-o prin proprietarul ei înainte de a o elimina, altfel schimbarea va părea o întrerupere cauzată de o corecție de securitate. Aceeași prudență se aplică unei rescrieri pe un port fix pe care se bazează în tăcere altceva.

Analiza expunerii este despre ce poate ajunge la ce, nu despre eticheta de pe ecran.

Decideți cu punctul final tradus în mână

Scrieți rezultatul regulii ca o propoziție: portul UDP public X ajunge la adresa Y portul Z. Apoi întrebați ce servicii de pe Y pot răspunde pe Z și cui aparțin.

nft list ruleset

Dacă răspunsul este singurul ascultător pe care l-ați intenționat, regula își face treaba.

Dacă răspunsul este mai multe, ați ales trimiterea către întreaga gazdă, indiferent dacă interfața a numit-o așa sau nu.

Articole similare