На яких портах насправді слухає 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 з юнітом або процесом і прочитайте конфігурацію цього сервісу. Якщо ви не можете назвати власника, ви не готові вирішувати що-небудь щодо сокета.
- Обсяг прив’язки. Loopback локальний для простору імен. Прив’язка wildcard доступна лише тоді, коли це дозволяють маршрутизація, фільтрація хоста й будь-які правила на рівні хмари, тому адреса прив’язки необхідна, але недостатня. Перевіряйте IPv4 і IPv6 як окремі рішення.
- Опублікований шлях. Шукайте переспрямування сервісу, переспрямування, специфічні для демонів, зовнішній проксі та чинну політику брандмауера. Це крок, який люди пропускають, і саме він перетворює нешкідливий на вигляд backend-порт на доступний адміністративний шлях.
Те саме питання читається інакше ззовні хоста. Порт без правила брандмауера хоста все ще може бути закритий хмарною групою безпеки, а порт із дозвільним правилом хоста може бути недоступним, бо до нього ніщо не маршрутизується. Подивіться на обидва кінці, перш ніж писати висновок інвентарю.
Де опублікований шлях відрізняється від списку сокетів
Власна документація Access Server охоплює випадок, який спричиняє найбільше плутанини: коли працює кілька демонів TCP, фронтальний порт переспрямовує на порти, специфічні для демонів, і видима розкладка перестає відповідати списку сокетів. посібник з фільтрації веб-інтерфейсу описує ці правила й те, чому фільтр, написаний лише для очевидного порту, може повністю оминути переспрямований шлях.
Керування кластером — друге місце, де важлива версія. Починаючи з 3.0 він ділить 943; старіші конфігурації кластера використовували 945. Відкриття або блокування одного з них без перевірки версії дає охайний на вигляд і неправильний інвентар.
Отже, зовні видима поверхня — це об’єднання трьох речей: слухаючих сокетів, правил переспрямування, які їх публікують знову, і мережевих контролів перед хостом. Будь-який інвентар, де записано лише перше, неповний, а будь-яка зміна, що враховує лише перше, або залишить шлях відкритим, або відріже сервіс.
Перевірте після будь-якої зміни
Змінюйте налаштування слухачів через підтримуваного власника конфігурації й тримайте відкритою консоль відновлення, поки це робите. Втрата адміністративного доступу до веб-інтерфейсу на віддаленому хості не відновлюється через VPN, який ви щойно вимкнули.
Потім перевірте чотири речі, які зазвичай потрібні розгортанню: VPN-клієнт підключається, клієнтський портал завантажується, адміністративний доступ працює, і зв’язок кластера досі функціонує, якщо ви запускаєте більше одного вузла. Тест лише VPN спокійно проходить, поки портал зламаний.
Завершіть, записавши дозволений шлях для кожного сервісу: який сокет, яка прив’язка, яке правило переспрямування, який мережевий контроль. Цей документ і є корисним результатом безпеки. Мінімальна кількість сокетів — ні, як і масове скидання, що закриває слухачі, які ніхто не встиг ідентифікувати.