Блог компании 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 | Enterprise-среда | Зоны, профили, сервисы |
Типичная ошибка - это оставить фаервол "на потом". Кажется что вот сервер подняли, сервисы работают, сайт открывается и на этом всё. Но через пару месяцев появляются странные запросы, нагрузка растёт, 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 без мифов: ссылки, упоминания бренда, репутация и поведенческие факторы. Практический чек-лист для оценки внешних сигналов и роста доверия сайта.
