Открытые порты и харденинг сервера

Как бы тщательно ни был написан код веб-приложения, проверяется и сервер, на котором оно работает. Одно из первых действий на официальной экспертизе — сканирование портов сервера снаружи. Если из интернета открыты не только 80 и 443, но и порты FTP, базы данных или панели управления, это попадает в отчёт отдельной находкой.

При экспертизе нашего собственного продукта (SaaS-платформы для налогового и финансового учёта) была именно такая находка: порты FTP и хостинг-панели были доступны из интернета. В этой статье расскажем, как мы её закрыли, и разберём основные шаги харденинга сервера.

Чем опасен открытый порт

Каждый открытый порт — это программа, которая общается с внешним миром. Чем их больше, тем больше поверхность атаки:

• FTP передаёт данные, включая логин и пароль, без шифрования. Кроме того, это типичная цель атак подбора паролей (brute force).
• Панели управления (хостинг-панель, веб-интерфейс базы данных) дают полный доступ к серверу. Если в самой панели найдётся уязвимость или утечёт пароль, последствия будут тяжёлыми.
• Порты баз данных (например, MySQL 3306, PostgreSQL 5432, Redis 6379) не должны быть открыты в интернет — приложение подключается к ним изнутри сервера.
• Забытые тестовые службы часто не обновляются и остаются со старыми уязвимостями.

Принцип: снаружи должна быть видна только та служба, которая нужна пользователям. Обычно это 443 (HTTPS) и 80 для перенаправления. Всё остальное — закрыто или открыто только для разрешённых адресов.

Шаг 1: выясните, что открыто

Сначала посмотрите изнутри сервера, какие службы и на каких адресах слушают:

sudo ss -tlnp

Обратите внимание на столбец Local Address:

• 127.0.0.1:... или [::1]:... — доступно только изнутри сервера, это хорошо;
• 0.0.0.0:..., *:... или [::]:... — слушает на всех сетевых интерфейсах; без firewall это открыто в интернет.

Затем проверьте снаружи. Делайте это с другого компьютера и только в отношении своего сервера:

nmap -Pn -p- your-server-ip

Сравните два списка. Для каждого открытого порта задайте вопрос: «кому и зачем нужна эта служба?»

Шаг 2: отключите лишние службы

Самая надёжная защита — когда служба вообще не запущена. Если FTP поставили один раз, чтобы загрузить файлы, отключите его и передавайте файлы через SFTP (по SSH) или через процесс деплоя:

sudo systemctl disable --now vsftpd

В нашем случае FTP вообще не был нужен — файлы и так доставлялись через SSH и git. Его остановка закрыла часть находки.

Службы баз данных и кеша привяжите только к локальному адресу. Например, для PostgreSQL в postgresql.conf:

listen_addresses = 'localhost'

Для Redis в redis.conf должна быть строка bind 127.0.0.1 ::1.

Шаг 3: firewall — по умолчанию закрыто

В Ubuntu самый простой путь — ufw. Основная идея: входящие подключения по умолчанию отклоняются, открываются только нужные порты.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Важно: перед ufw enable убедитесь, что порт SSH разрешён, иначе можно потерять доступ к серверу. Если SSH работает на нестандартном порту, укажите его.

Если сервер у облачного провайдера, не забывайте, что у провайдера есть и свой сетевой firewall (security group). Хорошая практика — настроить оба.

Шаг 4: спрячьте панель управления за allowlist

Инструменты вроде хостинг-панели часто нужны, и полностью отключить их не всегда возможно. В этом случае откройте порт панели только для определённых IP-адресов:

sudo ufw allow from 203.0.113.10 to any port 8888 proto tcp

Здесь 203.0.113.10 — постоянный IP офиса или администратора, 8888 — порт панели (замените на свой). Если постоянного IP нет, заходите в панель только через VPN или SSH-туннель:

ssh -L 8888:127.0.0.1:8888 user@your-server

После этого панель открывается в браузере по адресу http://127.0.0.1:8888, а снаружи её не видно. В нашем случае выбрали именно этот путь: порт панели закрыли для всех и оставили открытым только для списка разрешённых адресов.

Шаг 5: укрепите SSH

SSH должен оставаться открытым, поэтому его нужно укрепить. В файле /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Перед изменением убедитесь, что вход по ключу работает, затем sudo systemctl reload ssh. Дополнительно инструмент вроде fail2ban блокирует повторяющиеся неудачные попытки.

Дополнительный харденинг

• Регулярно обновляйте системные пакеты; в Ubuntu unattended-upgrades автоматически ставит обновления безопасности.
• Каждая служба должна работать под своим ограниченным пользователем, а не под root.
• Скрывайте версию сервера в ответах (server_tokens off).
• Следите за логами: входы по SSH, входы в панель, подключения, отклонённые firewall.
• После изменений снова запустите ss -tlnp и внешнее сканирование.

Стандарты

Эти требования соответствуют категории A05 «Security Misconfiguration» в OWASP Top 10 (2021). Документы CIS Benchmarks содержат подробные списки харденинга для Ubuntu и других систем — их удобно использовать как ориентир.

Итог

Открытые порты не требуют изменений в коде, но о них легко забыть. В нашем процессе Claude AI агент просматривает конфигурацию сервера и список слушающих служб, а специалист применяет правила firewall в безопасном порядке и повторно проверяет результат снаружи.

Если хотите узнать, как ваш сервер выглядит снаружи, оставьте заявку на сканирование. Мы поможем закрыть лишние службы до официальной экспертизы.