Pe ce porturi ascultă de fapt OpenVPN Access Server?

Rulați ss -lntup pe un host Access Server și obțineți o listă de două ori mai lungă decât era de așteptat. Jumătate dintre intrări sunt porturi în formă de daemon pe care nimeni nu le-a menționat la instalare. Reflexul este să închideți tot ce nu este 443 sau 1194, și așa își strică oamenii propriul portal de clienți.

Access Server nu este un singur ascultător. Este un serviciu VPN, un serviciu web și un participant la cluster, și poate genera porturi suplimentare specifice demonilor și redirecționări de firewall în funcție de câți demoni TCP ați configurat.

Parcurgeți inventarul în ordine: citiți socketurile, mapați-le pe cele cunoscute, clasificați restul după proprietar și legătură, apoi verificați ce le publică de fapt.

Începeți cu o singură comandă doar pentru citire

sudo ss -lntup vă oferă transportul, adresa locală, portul și procesul proprietar pentru fiecare socket care ascultă. Steagurile contează: -l ascultare, -n numeric, -t TCP, -u UDP, -p proces. Fără root obțineți socketurile dar nu și numele proceselor, iar aceea este exact coloana de care aveți nevoie pentru clasificare.

Notați patru câmpuri pe rând înainte de a vă forma o opinie: protocol, adresă de legătură, port și comandă. Țineți versiunea Access Server și numărul de demoni configurat lângă acea listă, pentru că ambele schimbă ceea ce este de așteptat.

Două rânduri care arată identic nu sunt. TCP și UDP pe același număr sunt socketuri separate cu expunere separată, iar 0.0.0.0 și :: sunt legături separate pentru familii de adrese separate. Un serviciu legat doar la 127.0.0.1 nu este accesibil direct de pe alt host, deși o redirecționare locală îl mai poate publica.

Ascultătorii pe care ar trebui să îi recunoașteți

Aceste valori implicite acoperă majoritatea implementărilor și vă oferă o bază de comparație. Sunt valori implicite, nu o listă completă de permisiuni.

Tot ce depășește asta are nevoie de o explicație, nu de o presupunere. Veți vedea des ascultători doar locali care aparțin unor componente pe care produsul le instalează pentru sine. Confirmați-i prin PID și configurația serviciului, nu printr-un număr de port memorat, și nu tratați un port necunoscut ca ostil doar pentru că este necunoscut.

Un socket în afara perechii cunoscute nu este nici el automat un rest. Când sunt configurați mai mulți demoni TCP, Access Server creează ascultători pe demon și redirecționează traficul către ei, așa că numărul și valorile porturilor urmează acea configurație.

Clasificați înainte de a închide ceva

Pentru fiecare rând incert, răspundeți la trei întrebări în această ordine.

1. Proprietar și scop. Asociați PID-ul cu o unitate sau un proces și citiți configurația acelui serviciu. Dacă nu puteți numi proprietarul, nu sunteți pregătit să decideți nimic despre socket.
2. Sfera legăturii. Loopback este local spațiului de nume. O legătură wildcard este accesibilă doar dacă rutarea, filtrarea hostului și orice reguli la nivel de cloud o permit, deci adresa de legătură este necesară dar nu suficientă. Verificați IPv4 și IPv6 ca decizii separate.
3. Cale publicată. Căutați redirecționarea serviciului, redirecționările specifice demonilor, un proxy extern și politica efectivă de firewall. Acesta este pasul pe care oamenii îl sar, și el este cel care transformă un port backend aparent inofensiv într-o cale administrativă accesibilă.

Aceeași întrebare se citește altfel din afara hostului. Un port fără regulă de firewall a hostului poate fi totuși închis de un grup de securitate din cloud, iar un port cu o regulă permisivă de host poate fi inaccesibil pentru că nimic nu rutează spre el. Uitați-vă la ambele capete înainte de a scrie concluzia inventarului.

Unde calea publicată diferă de lista de socketuri

Documentația proprie a Access Server acoperă cazul care provoacă cea mai multă confuzie: când rulează mai mulți demoni TCP, portul frontal redirecționează către porturi specifice demonilor, iar aspectul vizibil nu mai corespunde listei de socketuri. tutorialul despre filtrarea interfeței web descrie acele reguli și de ce un filtru scris doar pentru portul evident poate rata complet calea redirecționată.

Controlul clusterului este al doilea loc unde versiunea contează. Începând cu 3.0 partajează 943; configurațiile de cluster mai vechi foloseau 945. Deschiderea sau blocarea unuia dintre ele fără verificarea versiunii produce un inventar care pare îngrijit și este greșit.

Așadar, suprafața vizibilă din exterior este uniunea a trei lucruri: socketuri care ascultă, reguli de redirecționare care le republică și controalele de rețea din fața hostului. Orice inventar care înregistrează doar primul este incomplet, iar orice modificare care ia în considerare doar primul fie va lăsa o cale deschisă, fie va tăia un serviciu.

Verificați după orice modificare

Modificați setările ascultătorilor prin proprietarul de configurație acceptat și țineți deschisă o consolă de recuperare în timp ce faceți asta. Pierderea accesului administrativ la o interfață web pe un host la distanță nu se recuperează prin VPN-ul pe care tocmai l-ați dezactivat.

Apoi validați cele patru lucruri de care o implementare are nevoie de obicei: un client VPN se conectează, portalul de clienți se încarcă, accesul administrativ funcționează și comunicarea clusterului funcționează în continuare dacă rulați mai mult de un nod. Un test doar VPN trece confortabil în timp ce portalul este stricat.

Terminați notând calea permisă pentru fiecare serviciu: ce socket, ce legătură, ce regulă de redirecționare, ce control de rețea. Acel document este rezultatul de securitate util. Un număr minim de socketuri nu este, și nici o resetare în masă care închide ascultători pe care nimeni nu a terminat să îi identifice.