- Просмотр открытых портов
- Определение процесса по порту
- Закрытие ненужных портов
- Открытие порта для сервиса
- Проверка доступности порта извне
- Проверка TCP-порта
- Проверка UDP-порта
Сетевые порты в Linux – это один из базовых элементов, через которые система обменивается данными с внешним миром. Веб-серверы, базы данных, SSH-доступ, почтовые сервисы – все это работает через конкретные порты, и от того, как они настроены, напрямую зависят доступность сервисов и безопасность системы.
Умение управлять портами в Linux нужно не только системным администраторам. С этой задачей сталкиваются разработчики, DevOps-инженеры и все, кто разворачивает сервисы на сервере или в локальной среде. Открыть нужный порт, проверить, что он действительно слушается, закрыть лишнее и понять, какой процесс за что отвечает – базовые навыки, без которых сложно поддерживать систему в рабочем состоянии.
В этой статье разберем, как управлять портами в Linux на практике: какие инструменты для этого используются, как проверять открытые порты, управлять доступом и избегать типичных ошибок при настройке сети.
Просмотр открытых портов
Перед тем как открывать или закрывать порты, важно понять, какие из них уже используются системой. В Linux для этого есть несколько инструментов, но основной и самый универсальный – ss. Он установлен по умолчанию в большинстве дистрибутивов и постепенно вытесняет устаревший netstat.
Чтобы просмотреть все порты, которые находятся в состоянии прослушивания, выполните:
В выводе команды можно увидеть локальный адрес и порт, на котором сервис ожидает подключения. Например, 0.0.0.0:80 означает, что веб-сервер доступен на всех сетевых интерфейсах, а 127.0.0.1:631 – что сервис принимает соединения только с локальной машины.
На что смотреть в выводе:
- Local Address:Port указывает, на каком адресе и порту работает сервис.
Если видите 0.0.0.0:PORT или :::PORT, сервис доступен на всех интерфейсах (и потенциально снаружи).
Если 127.0.0.1:PORT, доступ только локальный. - Process – имя процесса, PID и иногда аргументы запуска.
Если нужно увидеть не только слушающие порты, но и активные подключения (кто к кому подключен), достаточно убрать -l:
Чтобы увидеть слушающие порты вместе с процессами (кто занял порт), выполните:
Посмотреть только TCP-порты (актуально для веба/SSH/БД):
Посмотреть только UDP (например, DNS, DHCP, syslog):
Если нужно проверить конкретный порт, вывод можно отфильтровать через grep:
Определение процесса по порту
Ситуация, когда порт уже занят и сервис не запускается, или наоборот – порт открыт, но непонятно кем, встречается регулярно. Тогда важно быстро определить, какой процесс использует нужный порт, и от какого пользователя он запущен.
Самый удобный инструмент для этого – все тот же ss. Он позволяет связать порт с конкретным процессом и его PID.
Найти процесс по номеру порта (например, 80) можно, выполнив:
В выводе будут видны:
- протокол (TCP или UDP);
- локальный адрес и порт;
- имя процесса;
- PID процесса;
- пользователь, от которого он запущен.
Если порт используется только по TCP, можно сузить вывод:
Если известен PID процесса, но нужно проверить, какие порты он использует, можно сделать обратную проверку:
Закрытие ненужных портов
Открытые порты – это точки входа в систему. Чем их больше, тем выше риск лишнего доступа и тем сложнее контролировать безопасность сервера. Поэтому после проверки запущенных сервисов логичный шаг – закрыть все порты, которые не используются и не должны быть доступны извне.
Но прежде чем закрыть порт, разберитесь почему он открыт. Если порт слушает процесс, который не нужен, правильнее остановить и отключить сам сервис, а не просто закрывать порт файрволом.
Остановить и отключить сервис можно, выполнив:
Затем проверьте его статус:
Если сервис не должен быть установлен вовсе, его можно удалить через пакетный менеджер – конкретная команда зависит от дистрибутива. Это самый надежный способ избавиться от порта: нечему слушать – нечего закрывать.
Если приложение позволяет, безопаснее привязать его только к localhost. Тогда порт будет доступен только на самой машине.
Пример логики настройки:
- привязка к 127.0.0.1 или localhost – доступ только локально;
- привязка к 0.0.0.0 или конкретному внешнему IP – доступ по сети.
Конкретные параметры зависят от приложения, но смысл один: сервис не должен слушать внешний интерфейс, если в этом нет необходимости.
Если сервис должен слушать сеть, но доступ нужно ограничить, используйте файрвол. В Linux чаще всего встречаются ufw (Ubuntu/Debian), firewalld (RHEL/CentOS/Fedora) и правила на базе iptables или nftables.
ufw и firewalld – это управляющие инструменты. Фактическая фильтрация трафика выполняется на уровне ядра именно через iptables или nftables:
- iptables – классический механизм управления сетевыми правилами. Правила применяются сразу, но не сохраняются после перезагрузки без дополнительной настройки.
- nftables – современная замена iptables с более компактным синтаксисом и лучшей производительностью. В новых дистрибутивах он считается основным механизмом фильтрации.
В большинстве случаев для закрытия портов удобнее использовать ufw или firewalld, так как они снижают риск ошибок. Прямая работа с iptables и nftables нужна, если требуется полный контроль над сетевой фильтрацией.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Во всех примерах выше используется порт 8080 исключительно для наглядности. На его месте может быть любой другой номер порта, который требуется закрыть – например 22, 80, 443, 3306 или любой пользовательский порт.
Проверьте, что правила файрвола применились:
UFW:
Firewalld:
iptables:
nftables:
После изменений проверьте результат: порт действительно должен исчезнуть из списка слушающих или стать недоступным извне.
sudo ss -tulnp | grep ':8080'
Открытие порта для сервиса
Открытие порта требуется в тех случаях, когда сервис должен принимать подключения извне: веб-сервер, база данных, VPN, почтовый сервер или любой другой сетевой сервис. Как и при закрытии портов, начинать стоит не с файрвола, а с самого сервиса.
Прежде всего убедитесь, что нужный сервис запущен и действительно слушает порт.
Проверьте, какой порт он использует и на каком интерфейсе слушает подключения:
Если сервис слушает только 127.0.0.1, он будет доступен лишь локально, и открытие порта в файрволе не даст результата. В этом случае необходимо изменить конфигурацию сервиса и разрешить прослушивание внешнего интерфейса.
После того как сервис запущен и слушает порт, доступ к нему нужно разрешить в файрволе. В Linux чаще всего используются ufw, firewalld или прямые правила через iptables / nftables.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
В примерах используется порт 8080 для наглядности. Его можно заменить на любой другой номер порта – например 22, 80, 443, 3306 или пользовательский порт сервиса.
Убедитесь, что правило добавлено и активно:
UFW:
Firewalld:
iptables:
nftables:
После изменений проверьте результат: порт должен слушаться процессом:
sudo ss -tulnp | grep ':8080'
Если сервис слушает порт, но подключение не проходит, чаще всего проблема в одном из пунктов: сервис привязан к localhost, открыто не тот протокол (TCP вместо UDP или наоборот), правило добавлено не в ту зону firewalld, либо выше по списку правил есть блокирующее правило.
Проверка доступности порта извне
Важно убедиться не только в том, что сервис запущен и порт слушается на сервере, но и в том, что к нему действительно можно подключиться извне. Локальная проверка через ss показывает состояние системы, но не отвечает на главный вопрос – проходит ли трафик через сеть и firewall.
Проще всего проверить порт с другой машины. Это может быть ваш локальный компьютер, другой сервер или любая система, находящаяся вне текущего хоста.
Проверка TCP-порта
Самый простой способ – использовать nc (netcat). Он показывает, удалось ли установить соединение.
Если порт доступен, вы увидите сообщение об успешном подключении. Ошибка или таймаут означает, что соединение блокируется или сервис недоступен.
Для веб-сервисов удобно использовать curl. Он сразу показывает, отвечает ли приложение:
Если сервер возвращает заголовки ответа, значит порт открыт и сервис принимает соединения. Ошибка соединения указывает на проблему с доступностью.
Проверка UDP-порта
С UDP все сложнее. Этот протокол не устанавливает соединение, поэтому отсутствие ответа не всегда означает, что порт закрыт. Многие UDP-сервисы отвечают только на корректные запросы своего формата.
Для базовой проверки можно использовать nc в UDP-режиме:
Заключение
Безопасная работа с портами сводится к простому принципу: открыто должно быть только то, что нужно, и только тем, кому это нужно. Что поможет вам держать ситуацию под контролем:
- Оставляйте открытыми только необходимые порты. Каждый открытый порт увеличивает поверхность атаки.
- Закрывайте причину, а не следствие. Если порт не нужен, сначала отключайте или удаляйте сервис. Firewall стоит использовать для ограничения доступа, а не для маскировки лишних процессов.
- Ограничивайте привязку по адресу. Сервисы, которые не должны быть доступны извне, привязывайте к 127.0.0.1.
- Открывайте доступ точечно по IP. Административные сервисы и панели управления не должны быть доступны всем.
- Разделяйте TCP и UDP. Всегда фиксируйте, по какому протоколу работает сервис. Открытый TCP не означает открытый UDP и наоборот. Ошибки на этом уровне часто выглядят как непонятные сетевые проблемы.
- Используйте принцип deny by default. Настройте брандмауэр так, чтобы все входящие подключения блокировались автоматически. А те порты, которые действительно нужны (например, 80 для веб-сервера), открывайте отдельными правилами.
- Контролируйте правила на всех уровнях. Проверяйте не только правила на сервере, но и настройки облачного файрвола, security group и сетевых ACL.
- Проверяйте доступность извне, а не только локально. ss показывает, что порт слушается, но не гарантирует доступ через сеть. Регулярно проверяйте порт с другой машины и фиксируйте результат.
- Следите за SSH-доступом. Не меняйте правила для SSH, пока у вас нет запасного способа зайти в систему. Перед применением новых правил держите открытую сессию, чтобы можно было все отменить, если потеряете доступ. Лучше перестраховаться, чем остаться без входа в сервер.
- Ведите учет и регулярно проверяйте правила. Поддерживайте список открытых портов и причин, почему они нужны. Периодически делайте ревизию: сервисы меняются, а правила часто остаются старыми.
- Обновляйте систему и сервисы. Открытый порт сам по себе не опасен, если сервис обновлен и правильно настроен. Уязвимости в старых версиях – одна из самых частых причин компрометации.
Придерживаясь этих правил, вы значительно снизите риски и упростите администрирование.