Кои портове всъщност слуша OpenVPN Access Server?
Прегледайте списъка със сокети на хост с Access Server: разпознайте слушателите по подразбиране, разграничете loopback от публикуваните и проверете пренасочването, преди да затворите порт.
Изпълнявате ss -lntup на хост с Access Server и получавате списък два пъти по-дълъг от очакваното. Половината записи са портове с форма на демон, за които никой не е споменавал при настройката. Рефлексът е да затворите всичко, което не е 443 или 1194, и точно така хората чупят собствения си клиентски портал.
Access Server не е един слушател. Той е VPN услуга, уеб услуга и участник в клъстер и може да генерира допълнителни портове, специфични за демони, и пренасочвания на защитната стена в зависимост от това колко TCP демона сте конфигурирали.
Прегледайте инвентара по ред: прочетете сокетите, нанесете познатите, класифицирайте останалите по собственик и обвързване, след което проверете какво всъщност ги публикува.
Започнете с една команда само за четене
sudo ss -lntup ви дава транспорта, локалния адрес, порта и собственика процес за всеки слушащ сокет. Флаговете имат значение: -l слушане, -n числово, -t TCP, -u UDP, -p процес. Без root получавате сокетите, но не и имената на процесите, а точно тази колона ви е нужна за класификация.
Записвайте четири полета на ред, преди да си съставите мнение: протокол, адрес на обвързване, порт и команда. Дръжте версията на Access Server и конфигурирания брой демони до този списък, защото и двете променят очакваното.
Два реда, които изглеждат еднакви, не са. TCP и UDP на един и същ номер са отделни сокети с отделна експозиция, а 0.0.0.0 и :: са отделни обвързвания за отделни семейства адреси. Услуга, обвързана само с 127.0.0.1, не е директно достъпна от друг хост, макар локално пренасочване все още да може да я публикува.
Слушателите, които трябва да разпознавате
Тези стойности по подразбиране покриват повечето внедрявания и ви дават базова линия за сравнение. Те са стойности по подразбиране, а не пълен списък с разрешения.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Всичко отвъд това изисква обяснение, а не предположение. Често ще виждате слушатели само за локален достъп, принадлежащи на компоненти, които продуктът инсталира за себе си. Потвърдете ги чрез PID и конфигурацията на услугата, а не чрез запомнен номер на порт, и не приемайте непознат порт за вражески само заради непознатостта.
Сокет извън познатата двойка също не е автоматично остатък. Когато са конфигурирани няколко TCP демона, Access Server създава слушатели за всеки демон и пренасочва трафика към тях, така че броят им и стойностите на портовете следват тази конфигурация.
Класифицирайте, преди да затворите нещо
За всеки несигурен ред отговорете на три въпроса в този ред.
- Собственик и предназначение. Съпоставете PID с unit или процес и прочетете конфигурацията на тази услуга. Ако не можете да назовете собственика, не сте готови да решавате нищо за сокета.
- Обхват на обвързване. Loopback е локален за пространството от имена. Обвързването с wildcard е достъпно само ако маршрутизацията, филтрирането на хоста и всички правила на облачно ниво го позволяват, така че адресът на обвързване е необходим, но недостатъчен. Проверете IPv4 и IPv6 като отделни решения.
- Публикуван път. Търсете пренасочване на услугата, пренасочвания, специфични за демони, външен прокси и ефективната политика на защитната стена. Това е стъпката, която хората пропускат, и тя е тази, която превръща безобидно изглеждащ backend порт в достъпен административен път.
Същият въпрос се чете различно отвън хоста. Порт без правило в защитната стена на хоста все още може да бъде затворен от облачна група за сигурност, а порт с разрешаващо правило на хоста може да е недостъпен, защото нищо не маршрутизира към него. Погледнете двата края, преди да напишете заключението на инвентара.
Къде публикуваният път се различава от списъка със сокети
Собствената документация на Access Server покрива случая, който създава най-много объркване: когато работят няколко TCP демона, фронталният порт пренасочва към портове, специфични за демоните, и видимото разположение спира да съвпада със списъка със сокети. А урокът за филтриране на уеб интерфейса описва тези правила и защо филтър, написан само за очевидния порт, може напълно да пропусне пренасочения път.
Клъстерният контрол е второто място, където версията има значение. В 3.0 и по-нови той споделя 943; по-старите клъстерни конфигурации използваха 945. Отварянето или блокирането на един от тях без проверка на версията създава инвентар, който изглежда подреден и е грешен.
Така външно видимата повърхност е обединението на три неща: слушащи сокети, правила за пренасочване, които ги публикуват отново, и мрежови контроли пред хоста. Всеки инвентар, който записва само първото, е непълен, и всяка промяна, която разглежда само първото, или ще остави път отворен, или ще отреже услуга.
Проверете след всяка промяна
Променяйте настройките на слушателя чрез поддържания собственик на конфигурацията и дръжте отворена конзола за възстановяване, докато го правите. Загубата на административен достъп до уеб интерфейс на отдалечен хост не се възстановява чрез VPN, който току-що сте изключили.
След това валидирайте четирите неща, които едно внедряване обикновено изисква: VPN клиент се свързва, клиентският портал се зарежда, административният достъп работи и клъстерната комуникация продължава да функционира, ако управлявате повече от един възел. Тест само на VPN минава спокойно, докато порталът е счупен.
Завършете, като запишете разрешения път за всяка услуга: кой сокет, кое обвързване, кое правило за пренасочване, коя мрежова контрола. Този документ е полезният резултат за сигурността. Минималният брой сокети не е, нито е масово нулиране, което затваря слушатели, които никой не е успял да идентифицира.