Блог компанії 3v-Hosting
15 хв.
Що таке порти? Найпростіше пояснити це за аналогією з будівлями, тоді ваш сервер можна уявити у вигляді якоїсь будівлі або фортеці, а порти тоді будуть дверима, що ведуть всередину цієї будівлі. Деякі з них повинні бути завжди відкриті, а деякі повинні бути суворо під замком. Ну а про існування третіх взагалі ніхто не повинен здогадуватися. І якщо зовні сервер виглядає як одна IP-адреса або домен, то всередині він живе бурхливим і насиченим життям. Всередині працюють веб-сервери, бази даних, панелі управління, поштові сервіси, API, черги, моніторинг і багато іншого. І всі ці сервіси спілкуються між собою і з зовнішніми сервісами через певні порти.
Неправильне управління портами є одним з найчастіших джерел проблем при роботі на VPS і виділених серверах. Погано продумана стратегія захисту і випадково залишений відкритим порт, на якому працює один з важливих сервісів, може призвести до катастрофічних наслідків, від банального «чому сайт не відкривається» у випадку DDoS до повноцінних зломів, витоків даних і раптових блокувань з боку провайдерів. При цьому тема портів здається простою тільки на перший погляд, але на практиці вона містить багато нюансів, особливо якщо сервер використовується не для банального хостингу одного сайту на Apache, а як повноцінна робоча інфраструктура.
У цій статті ми спробуємо розібратися, як грамотно керувати портами на VPS або виділеному сервері, які інструменти для цього використовувати і де найчастіше роблять помилки навіть досвідчені адміністратори.
Отже, якщо спростити, то порт - це логічний номер, через який сервіс приймає або відправляє мережеві з'єднання. І якщо IP-адреса відповідає на питання, куди відправляти пакети, то порт відповідає на питання, якому сервісу призначені ці пакети даних.
Класичні приклади портів відомі всім:
Але сучасний сервер рідко обмежується цим стандартним набором. Варто додати панелі управління, Docker-контейнери, внутрішні API, webhook'и, системи моніторингу - і кількість активних портів легко може перевищити кілька десятків.
І проблема в тому, що кожен відкритий порт - це потенційна точка входу. Не обов'язково для злому, іноді просто для зайвого навантаження, сканування або автоматичних ботів. Тому управління портами є не разовим налаштуванням після установки системи, а перетворюється на постійний процес.
Для зручності управління корисно розділяти порти за призначенням:
| Тип портів | Приклади | Призначення |
|---|---|---|
| Публічні | 80, 443 | Доступні для всіх користувачів |
| Адміністративні | 22, 2087, 8443 | Керування сервером |
| Внутрішні сервіси | 3306, 5432, 6379 | Взаємодія між сервісами |
| Службові / тимчасові | 8080, 9000 | Тестування, міграції, налагодження |
Такий поділ допомагає відразу зрозуміти, які порти повинні бути доступні з інтернету, а які можуть бути доступні строго всередині сервера або приватної мережі.
Перший крок у будь-якому аудиті - це просто зрозуміти, що взагалі відбувається на сервері тут і зараз. Дуже часто адміністратор впевнений, що у нього відкритий тільки SSH і сам сайт, тому що саме ці сервіси він налаштовував свідомо. Але реальність майже завжди буває складнішою.
На практиці сервер може слухати ще десяток портів, адже на сервері запущені й інші сервіси, наприклад сервіси моніторингу, бази даних, тимчасові веб-сервери для тестів, контейнери, панелі управління, агенти резервного копіювання тощо. Частина з них могла з'явитися автоматично при встановленні пакетів, частина просто залишитися після експериментів або міграцій, а про деякі адміністратор просто забув.
Проблема в тому, що серверу все одно, пам'ятаєте ви про ці порти чи ні, і якщо порт слухається і не закритий фаєрволом, він доступний ззовні. Тому перед тим, як щось закривати або налаштовувати, важливо спочатку побачити реальну картину, які саме порти активні в даний момент, які процеси за ними стоять і на яких інтерфейсах вони доступні. Саме з цього і починається грамотне управління портами.
На Linux є кілька базових інструментів. Найуніверсальніший спосіб побачити, які порти реально слухаються сервісами:
ss -tulpen
Ця команда показує:
Також існує кілька альтернативних варіантів для перегляду відкритих портів:
Ключовий момент: важливо бачити не тільки порт, але і який процес його використовує. Часто порт відкритий не тому, що ви його свідомо включили, а тому, що сервіс стартував з налаштуваннями за замовчуванням.
Сервер може слухати порт, але він може бути закритий фаєрволом. Тому корисно дивитися на ситуацію очима зовнішнього клієнта:
lsof -i -P -n
або
netstat -tulpen
А якщо ви хочете подивитися ззовні на свій сервер, тоді можна скористатися найпотужнішим інструментом nmap:
nmap -Pn your.server.ip
І саме так сервер бачать браузери, боти і сканери.
Управляють портами не сервіси і не конкретні додатки, а управляє ними фаєрвол. Саме він є останнім і найважливішим рубежем, який вирішує, хто і до чого може підключатися на сервері. Сервіс може слухати порт, але якщо фаєрвол забороняє вхідні з'єднання, цей порт фактично «не існує» для зовнішнього світу.
На VPS і виділених серверах під Linux найчастіше використовують такі системні фаєрволи:
Незалежно від конкретного інструменту, принцип у всіх один і той же: дозволено тільки те, що явно дозволено. Все інше має бути заборонено за замовчуванням. Це базова модель безпеки, яка працює десятиліттями, описана в величезній кількості мануалів, але досі регулярно порушується.
Типова ситуація виглядає так, що фаєрвол або взагалі не налаштований, або дозволяє занадто багато, ніби про всяк випадок. В результаті сервер стає доступним не тільки для потрібних сервісів, але і для сканерів, ботів і автоматичних атак. При цьому проблеми можуть проявлятися не відразу. Наприклад, спочатку починає зростати фонове навантаження, потім з'являються дивні підключення, а потім IP сервера раптово опиняється в чорних списках.
Грамотно налаштований фаєрвол вирішує відразу кілька ключових завдань: знижує поверхню атаки, зменшує зайвий мережевий трафік і робить поведінку сервера передбачуваною. Саме тому управління портами завжди повинно починатися з фаєрвола, а не з окремих сервісів або додатків.
Вибір фаєрвола залежить не стільки від вибору «правильного інструменту», скільки від контексту використання сервера і рівня вашої залученості в адміністрування. Всі сучасні фаєрволи в Linux вирішують одне і те ж завдання з контролю мережевих з'єднань, але роблять це на різному рівні абстракції.
Якщо у вас одиночний VPS, типовий стек і немає завдання будувати складну мережеву логіку, найчастіше розумно вибрати UFW. Він закриває 90% практичних сценаріїв і дозволяє швидко зрозуміти поточний стан правил без глибокого занурення в мережеві деталі. Це хороший варіант, якщо сервер повинен бути безпечним, але при цьому легко обслуговуваним.
iptables і nftables підходять в ситуаціях, де потрібен повний контроль, наприклад при використанні нестандартних мережевих схем, тонкої фільтрації трафіку, високому навантаженні або інтеграції з іншими системами безпеки. Ціною такого контролю є складність. Такі фаєрволи вимагають акуратності, документації і розуміння того, як саме пакети проходять через систему.
firewalld зазвичай вибирають в більш структурованих середовищах, таких як корпоративні сервери, кластери, системи з поділом на зони довіри. Він зручний, коли серверів багато і важливо керувати правилами логічно, а не набором розрізнених команд.
Який би інструмент не був обраний, важливо пам'ятати, що фаєрвол - це не одноразове налаштування, а частина інфраструктури. Він повинен бути зрозумілий вам і вашій команді, інакше з часом правила перетворюються на хаотичний набір винятків, який бояться чіпати.
| Інструмент | Підходить для | Особливості |
|---|---|---|
| UFW | VPS, окремі сервери | Простий та зрозумілий синтаксис |
| iptables / nftables | Просунуті конфігурації | Максимальний контроль і гнучкість |
| firewalld | Корпоративне середовище | Зони, профілі, керування сервісами |
Типова помилка - це залишити фаєрвол «на потім». Здається, що ось сервер підняли, сервіси працюють, сайт відкривається і на цьому все. Але через пару місяців з'являються дивні запити, навантаження зростає, IP потрапляє в чорні списки і т.д., і т.п.
Грамотна стратегія завжди однакова:
SSH - це, мабуть, найбільш атакований сервіс на будь-якому сервері. І це не абстрактна загроза з підручників з безпеки, а повсякденна реальність. Досить подивитися логи всього через кілька хвилин після установки системи, щоб побачити десятки автоматичних спроб підключення з різних IP-адрес.
Боти постійно сканують інтернет у пошуках відкритого SSH, перебирають логіни, пробують стандартні паролі та застарілі конфігурації. Їм не важливо, що саме працює на сервері і кому він належить, просто будь-який доступний порт сприймається як потенційна мета, іноді для жартів, навчання або самоствердження, а іноді і для зловмисних дій. Саме тому SSH вимагає особливої уваги при управлінні портами і ніколи не повинен залишатися налаштованим за замовчуванням.
Базові заходи, які давно стали стандартом:
Звичайно, просте перенесення SSH з 22-го порту не робить сервер «невидимим», але вже сильно знижує шум від автоматичних ботів. Це фільтр, а не повноцінний захист. Реальна безпека будується на ключах, фаєрволі та контролі доступу.
Порти 80 і 443 майже завжди відкриті за замовчуванням, і в більшості випадків це виправдано. Саме через них користувачі отримують доступ до сайтів і API. Однак навіть у цій, здавалося б, звичній зоні є нюанси, які часто залишаються без уваги.
Якщо сервер використовується виключно під HTTPS, то порт 80 фактично потрібен тільки для перенаправлення на захищене з'єднання. У всіх інших випадках він просто приймає вхідні підключення, створюючи зайвий мережевий шум і додаткову поверхню атаки. Особливо це помітно на серверах з високою відвідуваністю або при активному скануванні з боку ботів.
Окрема категорія проблем - це забуті тестові та допоміжні сервіси. У процесі налаштування легко запустити додатковий веб-сервер на 8080, 8000 або 3000 «тимчасово», щоб щось перевірити. Але після завершення робіт про цей порт часто забувають. В результаті через місяці або навіть роки сервіс все ще доступний з інтернету, хоча більше не використовується і не оновлюється.
У складних конфігураціях з реверс-проксі, балансуванням навантаження і декількома сайтами ризик зростає ще сильніше. Згодом сервер обростає тимчасовими рішеннями, міграціями і експериментами, і без регулярної перевірки стає складно зрозуміти, які порти дійсно потрібні для роботи, а які залишилися у спадок від минулих етапів розвитку інфраструктури.
Відкриті порти баз даних - одна з найнебезпечніших і, на жаль, поширених помилок в серверній інфраструктурі. Часто вона виникає не через злий умисел, а через неуважність або неправильні налаштування за замовчуванням.
MySQL, PostgreSQL, MongoDB та інші СУБД спочатку проектувалися для роботи всередині довіреного середовища, в рамках одного сервера, в приватній мережі або всередині кластера. Тому вони не розраховані на прямий доступ з інтернету і якщо порт бази даних доступний ззовні, це майже завжди означає проблему в архітектурі або налаштуваннях безпеки.
Навіть при наявності складних паролів і обмежень по користувачах відкритий порт СУБД стає постійною ціллю для автоматичних сканерів, перебору облікових даних і спроб перевантажити сервіс. У кращому випадку це призведе до зайвого навантаження і логів, а в гіршому - до витоку конфіденційних даних або повної компрометації системи.
localhost або приватний інтерфейс;
Отже, навіть при складних паролях і ролях, відкритий порт БД - це категорично неправильно.
Контейнери легко створюють відчуття ізоляції та безпеки. Docker візуально відокремлює сервіси один від одного, і через це виникає помилкове враження, що все, що запущено в контейнері, за замовчуванням приховано від зовнішнього світу. Але на практиці публікація портів Docker працює безпосередньо через хостову систему.
Достатньо одного рядка в docker-compose.yml, щоб сервіс став доступним з інтернету:
ports: - «8080:8080»
Після цього Docker прив'язує порт контейнера до мережевого інтерфейсу хоста, найчастіше до 0.0.0.0.
Якщо фаєрвол при цьому не обмежує доступ, сервіс стає публічним, незалежно від того, планувалося це чи ні. Особливо небезпечно, що такі прокидання часто додаються ніби тимчасово, для тестування або налагодження, але потім залишаються в конфігурації надовго.
Саме тому Docker вимагає такого ж уважного ставлення до портів, як і будь-які інші сервіси на вашому сервері, оскільки кожен опублікований порт повинен бути усвідомленим, задокументованим і захищеним.
Підсумуємо: При роботі з контейнерами часто трапляються ситуації, яких слід уникати. Серед таких ситуацій:
0.0.0.0;| Механізм | Що робить | Рівень ризику |
|---|---|---|
| Docker ports | Прямий проброс портів | Високий |
| NodePort | Відкриває порт на всіх нодах | Середній |
| LoadBalancer | Надає публічну IP-адресу | Контрольований |
| Ingress | Єдина точка входу для сервісів | Найбезпечніший |
Тому без розуміння мережевої моделі легко отримати десятки відкритих портів, про які ніхто не пам'ятає, чим викликати пильну увагу зловмисників до свого сервера.
Згодом в адмініструванні серверів повторюються одні й ті ж сценарії, незалежно від досвіду і розміру інфраструктури. Помилки накопичуються поступово і часто виглядають нешкідливо в даний момент, але саме вони створюють більшість проблем в майбутньому:
Порти люблять порядок і прозорість. Коли цього порядку немає, сервер поступово перетворюється на хаотичну конструкцію, де будь-яка зміна стає ризикованою: закрили, здавалося б, зайвий порт - впав сервіс, відкрили новий порт - з'явилася незрозуміла поведінка в логах. У такому стані інфраструктура перестає бути керованою і починає працювати проти адміністратора, а не допомагати йому.
Так. Якщо сервіс не використовується, порт повинен бути закритий фаєрволом. Навіть якщо процес зараз не запущений, конфігурація може змінитися, сервіс може стартувати автоматично після оновлення або перезавантаження, і порт знову стане доступним ззовні без вашого відома. Закритий порт - це явний сигнал системі та адміністратору, що доступ до нього не передбачається.
Використання нестандартних портів дійсно знижує кількість автоматичних сканувань і брутфорсу, оскільки більшість ботів орієнтується на стандартні значення. Однак це лише додатковий фільтр, а не повноцінний захід безпеки. Нестандартний порт завжди повинен поєднуватися з фаєрволом, обмеженням по IP і надійною аутентифікацією.
Ні. Фаєрвол провайдера - це зовнішній рівень захисту, який не знає, які сервіси і порти використовуються всередині системи. Він не замінює системний фаєрвол і не захищає від помилок конфігурації на самому сервері. Надійна схема завжди включає обидва рівні, зовнішній і локальний.
Небезпечно, якщо ви не закриєте його відразу після виконання завдання. Тимчасові порти часто залишаються відкритими довше, ніж планувалося, особливо в робочій метушні. Згодом такі винятки накопичуються і перетворюються на неконтрольований набір правил, який складно аналізувати і підтримувати.
Так, і це один з найкращих варіантів, якщо сервіс повинен бути доступний обмеженому колу клієнтів або адміністраторів. Обмеження по IP істотно знижує ризик атак і дозволяє безпечно використовувати адміністративні та внутрішні сервіси без публікації їх в інтернет.
Регулярно. Мінімум - при кожній зміні інфраструктури, встановленні нових сервісів або оновленні контейнерів. В ідеалі аудит портів повинен бути частиною планового обслуговування сервера, так само як перевірка оновлень або резервного копіювання.
Управління портами на VPS або виділеному сервері - це не набір команд і не одноразове налаштування після встановлення системи. Це частина загальної дисципліни адміністрування і розуміння того, як саме сервер взаємодіє із зовнішнім світом, користувачами та іншими сервісами.
Кожен відкритий порт повинен бути усвідомленим рішенням і конкретним зобов'язанням. За ним повинен стояти зрозумілий сервіс, обмежений доступ і чітке розуміння, навіщо цей порт існує і хто має до нього доступ. Все, що не виконує цю роль, повинно бути закрито, без винятків і «про всяк випадок».
Коли до портів ставляться системно, тобто проводять регулярний аудит, використовують фаєрвол як основний інструмент контролю, акуратно працюють з Docker і базами даних, то інфраструктура стає передбачуваною і стійкою. У такому стані сервер перестає бути джерелом несподіваних проблем, інцидентів і нічних аварій, а починає виконувати своє головне завдання - стабільно і безпечно працювати на ваш бізнес.
Повний огляд застосувань VPS: реальні приклади, інфраструктура для бізнесу, VPN, CI/CD та середовища розробки. Допомагає вибрати оптимальний сервер.
Перше про що повинен замислюватися кожен системний адміністратор чи власник сайту – це безпека. І найпопулярнішим досі інструментом, що допомагає захиститися ві...
У нинішню епоху цифровізації підприємства значною мірою покладаються на надійні рішення для задоволення потреб бізнесу. Коли мова заходить про хостинг, на думку...
Оптимізація Windows Server 2022 на VPS з 2-4 ГБ RAM: як система витрачає пам'ять, що можна безпечно налаштувати, pagefile, служби, GUI і коли апгрейд RAM розумн...
GitOps - це підхід до управління інфраструктурою та Kubernetes через Git як єдине джерело істини. Він спрощує розгортання, знижує ризики, усуває дрейф конфігура...
Off-page SEO без міфів: посилання, згадки про бренд, репутація та поведінкові фактори. Практичний чек-лист для оцінки зовнішніх сигналів і зростання довіри до с...
