Mely portokon figyel valójában az OpenVPN Access Server?

Ön futtatja a ss -lntup parancsot egy Access Server-gazdagépen, és a vártnál kétszer hosszabb listát kap. A bejegyzések fele démon alakú port, amelyet senki nem említett a telepítés során. A reflex az, hogy mindent bezárnak, ami nem 443 vagy 1194, és így törik el az emberek a saját ügyfélportáljukat.

Az Access Server nem egyetlen figyelő. Ez egy VPN-szolgáltatás, egy webszolgáltatás és egy klaszterrésztvevő, amely a konfigurált TCP-démonok számától függően további démonspecifikus portokat és tűzfal-átirányításokat hozhat létre.

Járja végig a leltárt sorrendben: olvassa el a socketeket, képezze le az ismerőseket, sorolja be a többit tulajdonos és kötés szerint, majd ellenőrizze, mi teszi közzé őket valójában.

Kezdje egyetlen csak olvasható paranccsal

sudo ss -lntup megadja a szállítást, a helyi címet, a portot és a tulajdonos folyamatot minden figyelő sockethez. A kapcsolók számítanak: -l figyelés, -n numerikus, -t TCP, -u UDP, -p folyamat. Root nélkül megkapja a socketeket, de a folyamatneveket nem, és pontosan erre az oszlopra van szüksége az osztályozáshoz.

Mielőtt bármilyen véleményt alkotna, jegyezzen fel soronként négy mezőt: protokoll, kötési cím, port és parancs. Tartsa az Access Server verzióját és a konfigurált démonszámot a lista mellett, mert mindkettő megváltoztatja azt, ami várható.

Két egyformán kinéző sor nem egyforma. Az azonos számú TCP és UDP külön socketek, külön kitettséggel, és 0.0.0.0 és :: külön kötések külön címcsaládokhoz. Az csak a 127.0.0.1 címhez kötött szolgáltatás más gazdagépről nem érhető el közvetlenül, bár egy helyi átirányítás még közzéteheti.

A figyelők, amelyeket fel kell ismernie

Ezek az alapértékek a legtöbb telepítést lefedik, és összehasonlítási alapot adnak. Alapértékek, nem teljes engedélyezési lista.

Minden, ami ezen túl van, magyarázatot igényel, nem feltételezést. Gyakran lát majd csak helyi figyelőket, amelyek olyan összetevőkhöz tartoznak, amelyeket a termék saját maga számára telepít. Erősítse meg őket PID és szolgáltatáskonfiguráció alapján, ne egy megjegyzett portszám alapján, és ne tekintse ellenségesnek az ismeretlen portot pusztán azért, mert ismeretlen.

Az ismert párton kívüli socket sem feltétlenül maradvány. Ha több TCP-démon van konfigurálva, az Access Server démononként figyelőket hoz létre, és átirányítja rájuk a forgalmat, így számuk és portértékeik ezt a konfigurációt követik.

Osztályozzon, mielőtt bármit bezár

Minden bizonytalan sorhoz válaszoljon három kérdésre ebben a sorrendben.

1. Tulajdonos és cél. Párosítsa a PID-et egy unithoz vagy folyamathoz, és olvassa el annak a szolgáltatásnak a konfigurációját. Ha nem tudja megnevezni a tulajdonost, nem áll készen arra, hogy bármit eldöntsön a socketről.
2. Kötési hatókör. A loopback a névtérhez helyi. A wildcard-kötés csak akkor érhető el, ha az útválasztás, a gazdagép szűrése és bármilyen felhőszintű szabály engedi, tehát a kötési cím szükséges, de nem elégséges. Ellenőrizze az IPv4-et és az IPv6-ot külön döntésként.
3. Közzétett útvonal. Keressen szolgáltatástovábbítást, démonspecifikus átirányításokat, külső proxyt és a tényleges tűzfalszabályzatot. Ez az a lépés, amelyet az emberek kihagynak, és ez az, amely egy ártalmatlannak látszó backend portot elérhető adminisztratív útvonallá tesz.

Ugyanaz a kérdés másképp olvasható a gazdagépen kívülről. Egy gazdagép-tűzfalszabály nélküli portot még mindig bezárhat egy felhő biztonsági csoport, és egy megengedő gazdagépszabállyal rendelkező port elérhetetlen lehet, mert semmi nem irányít oda. Nézze meg mindkét végét, mielőtt megírja a leltár következtetését.

Ahol a közzétett útvonal eltér a socketlistától

Az Access Server saját dokumentációja lefedi azt az esetet, amely a legtöbb zavart okozza: amikor több TCP-démon fut, az elülső port démonspecifikus portokra továbbít, és a látható elrendezés már nem egyezik a socketlistával. A webes felület szűréséről szóló útmutató leírja ezeket a szabályokat, és hogy miért hagyhatja ki teljesen az átirányított útvonalat egy csak a nyilvánvaló portra írt szűrő.

A klasztervezérlés a második hely, ahol a verzió számít. A 3.0-s és újabb verziókban a 943-at használja; a régebbi klaszterkonfigurációk a 945-öt használták. Ha a verzió ellenőrzése nélkül nyitja meg vagy blokkolja valamelyiket, rendezettnek látszó és hibás leltárt kap.

Tehát a kívülről látható felület három dolog uniója: figyelő socketek, az őket újraközzétevő továbbítási szabályok és a gazdagép előtti hálózati vezérlők. Minden leltár, amely csak az elsőt rögzíti, hiányos, és minden változtatás, amely csak az elsőt veszi figyelembe, vagy nyitva hagy egy útvonalat, vagy elvág egy szolgáltatást.

Minden változtatás után ellenőrizze

A figyelő beállításait a támogatott konfigurációtulajdonoson keresztül módosítsa, és közben tartson nyitva egy helyreállítási konzolt. Egy távoli gazdagépen lévő webes felület adminisztratív elérésének elvesztése nem állítható helyre azzal a VPN-nel, amelyet épp most tiltott le.

Ezután ellenőrizze azt a négy dolgot, amelyre egy telepítésnek általában szüksége van: egy VPN-kliens csatlakozik, az ügyfélportál betöltődik, az adminisztratív hozzáférés működik, és a klaszterkommunikáció továbbra is működik, ha egynél több csomópontot futtat. A csak VPN-t vizsgáló teszt kényelmesen átmegy, miközben a portál hibás.

Fejezze be azzal, hogy felírja az egyes szolgáltatások engedélyezett útvonalát: melyik socket, melyik kötés, melyik továbbítási szabály, melyik hálózati vezérlő. Ez a dokumentum a hasznos biztonsági eredmény. A minimális socket szám nem az, és egy tömeges visszaállítás sem, amely olyan figyelőket zár be, amelyeket senki nem fejezett be azonosítani.