Миф: смена порта SSH решает проблему безопасности

MAATRIX

Рано или поздно любой, кто администрирует сервер, натыкается на совет «перевесь SSH с 22 порта на что-нибудь вроде 2222 — и ботов сразу поубавится». Совет не врёт: шум в логах действительно падает. Но дальше начинается путаница — часть администраторов делает из этого вывод «значит, сервер теперь защищён» и на этом успокаивается. Разберём, что смена порта реально даёт, а что — только иллюзия, и почему разница между этими двумя вещами может стоить вам сервера.

Что на самом деле происходит при смене порта

Начнём с того, что миф не рождается на пустом месте. Если вы откроете /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/AlmaLinux) на свежесозданном VPS с SSH на стандартном 22 порту, буквально в первые минуты после запуска вы увидите десятки строк вида:

Failed password for root from 185.220.101.4 port 51223 ssh2
Failed password for invalid user admin from 45.155.205.19 port 40112 ssh2
Failed password for invalid user test from 92.118.39.74 port 33021 ssh2

Это не целенаправленная атака на вас лично. Это фоновый интернет-шум: боты вроде тех, что построены на базе массовых сканеров, круглосуточно перебирают диапазоны IP-адресов и стучатся именно в порт 22, потому что подавляющее большинство серверов в интернете держит SSH именно там. Экономика такого сканирования простая — искать везде подряд по умолчанию дешевле, чем сканировать все порты у каждого хоста.

Если вы переносите SSH на нестандартный порт (скажем, 22345) в /etc/ssh/sshd_config:

Port 22345

и перезапускаете службу:

sudo systemctl restart sshd

— то этот фоновый шум почти полностью исчезает. Не потому что сервер стал недоступен для атаки, а потому что вы выпали из списка целей ленивых автоматических ботов, которые проверяют только порт 22. Это реальный, измеримый эффект: логи становятся чище, легче искать в них что-то содержательное, меньше ложных срабатываний в мониторинге. Собственно это и есть техника, которую в информационной безопасности называют security through obscurity — «безопасность через неясность». Как способ снизить фоновый шум она работает буквально. Проблема начинается там, где из «снижает шум» делают вывод «решает проблему безопасности».

Почему это не защита, а фильтр шума

Ключевое отличие: смена порта ничего не скрывает от того, кто действительно смотрит на ваш сервер. Она отсеивает только тех ботов, которые запрограммированы проверять исключительно 22 порт и не идут дальше. А таких ботов — большинство, но не все, и уж точно не те, кто представляет реальную угрозу именно для вас.

Если ваш сервер стал целью не случайного скана, а конкретного человека — потому что вы засветили IP в утекшей базе, потому что домен связан с вашим бизнесом, потому что вас выбрали для атаки на цепочку поставок, — нестандартный порт не создаст для него никакой преграды. Обнаружение открытых портов — это первый и самый тривиальный шаг разведки, который проходят за секунды-минуты, а не за дни.

Как быстро находят нестандартный порт: разведка занимает минуты

Вот тут стоит закрыть вопрос конкретными цифрами, без мифологии в обе стороны. Современные инструменты для сканирования портов — например masscan — умеют опрашивать всё адресное пространство на десятках гигабит в секунду. Полное сканирование одного хоста по всем 65535 портам TCP занимает у таких инструментов не часы и не дни, а буквально секунды-минуты в зависимости от сетевых условий и настроек скорости сканирования. Точную цифру в секундах называть не будем — она зависит от канала, лимитов на стороне цели и параметров запуска, — но порядок величины принципиален: это не защита, рассчитанная на то, что атакующий «не станет тратить время».

Пример команды, которой атакующий может закрыть вопрос «где у них SSH» за один проход:

masscan -p1-65535 203.0.113.10 --rate 10000

Дальше достаточно nmap -sV по найденному порту, чтобы определить, что это именно SSH-демон, и какая у него версия:

nmap -sV -p 22345 203.0.113.10

Итог: нестандартный порт добавляет атакующему ровно один дополнительный шаг разведки, который автоматизирован и занимает исчезающе мало времени. Это защита от ленивых массовых ботов, но не от направленной атаки — и важно называть вещи своими именами, чтобы не спутать первое со вторым.

Смена порта не устраняет саму уязвимость

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

Разберём это на двух конкретных примерах.

Слабый пароль. Если на сервере разрешён вход по паролю и пароль пользователя — что-то вроде Qwerty123 или совпадает с логином, — то этот пароль одинаково слаб что на 22 порту, что на 55000. Единственное, что изменится при переносе на нестандартный порт — резко упадёт количество автоматических попыток подбора, потому что боты туда не постучатся. Но если атакующий узнает порт (а он узнает — см. предыдущий раздел) и запустит перебор именно по нему, слабый пароль сдастся так же легко, как и на порту 22.

Устаревшая версия SSH с известной CVE. Если на сервере крутится демон OpenSSH с неисправленной уязвимостью удалённого выполнения кода или обхода аутентификации, эта уязвимость эксплуатируется по номеру CVE и версии продукта — эксплойт обращается к порту, на который указывает атакующий, а не к порту 22 по умолчанию. Смена порта не патчит бинарник и не убирает уязвимый код. Единственное реальное лечение здесь — обновление пакета:

sudo apt update && sudo apt upgrade openssh-server

или для RHEL-подобных систем:

sudo dnf update openssh-server

Стоит держать в голове и то, что мы сознательно не приводим здесь конкретные номера CVE и версии — они устаревают быстрее, чем живёт статья, и называть версию без проверки на момент чтения было бы нечестно по отношению к вам. Правило простое и универсальное: проверяйте актуальность пакета openssh-server на дату, а не полагайтесь на память о том, что «вроде бы всё патчили в прошлом году».

Ложное чувство защищённости — реальный практический вред

Это, возможно, самый недооценённый пункт мифа. Смена порта не просто «не добавляет защиты» — она иногда действует во вред, потому что создаёт психологический эффект «я уже защитился». А дальше это чувство начинает влиять на реальные решения администратора.

Типичный сценарий: администратор переносит SSH на нестандартный порт, видит, что логи стали чище, и откладывает на потом внедрение более трудоёмких, но реально работающих мер:

• «Включу вход по SSH-ключам и отключу пароли как-нибудь потом, порт-то я уже сменил»;
• «fail2ban поставлю на следующей неделе, сейчас и так тихо в логах»;
• «root-логин пусть остаётся, порт нестандартный, кто туда полезет».

Проблема в том, что «стало тихо в логах» и «стало безопасно» — это два разных утверждения, и первое ложно подсказывает второе. Смена порта снимает симптом (шум от массовых ботов), но не убирает причину риска (пароль, конфигурация, версия ПО). Хуже того — снижение видимого шума в логах может усыпить бдительность именно тогда, когда стоило бы наоборот усилить мониторинг: раз массовый шум ушёл, всё, что осталось во входящих подключениях на нестандартном порту, с большей вероятностью — не случайный бот, а нечто более целенаправленное, и на это стоит смотреть внимательнее, а не меньше.

Что реально закрывает проблему безопасности SSH

Если выстроить меры по убыванию реального эффекта, а не по простоте внедрения, картина будет такой:

Обратите внимание: смена порта — внизу таблицы не потому что она бесполезна, а потому что она решает другую, менее критичную задачу (чистота логов), а не задачу собственно безопасности доступа.

Практический набор команд для перехода на ключи и отключения пароля в /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

После правки конфигурации — обязательно проверьте, что вход по ключу уже настроен и работает в отдельной сессии, прежде чем закрывать текущую, и только потом перезапускайте службу:

sudo systemctl restart sshd

Про то, как сгенерировать и разложить ключи с нуля, у нас есть отдельный подробный разбор — не будем повторять его здесь, чтобы не дублировать материал: SSH-ключи вместо пароля на сервере — частые ошибки и решения.

Для fail2ban логика похожая: сервис читает auth.log и после нескольких неудачных попыток входа с одного IP добавляет этот IP в бан на файрволе на заданное время. Подробная установка и разбор типичных ошибок конфигурации — в отдельной статье: Как установить и настроить fail2ban на VPS.

Практическая конфигурация: порт как один слой из нескольких

Здесь важно не впасть в противоположную крайность и не сказать «раз смена порта не панацея — значит, она бессмысленна». Она осмысленна ровно в той роли, для которой годится: как один из нескольких независимых слоёв защиты, каждый из которых закрывает свою часть риска. Комбинация выглядит примерно так:

# /etc/ssh/sshd_config

Port 22345
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers deploy admin

Плюс файрвол, ограничивающий доступ к порту SSH только нужными подсетями там, где это применимо:

sudo ufw allow from 203.0.113.0/24 to any port 22345 proto tcp
sudo ufw deny 22345/tcp

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

В такой конфигурации смена порта не создаёт ложного чувства защищённости, потому что она не единственная мера — она просто один из пунктов списка, который снижает нагрузку на остальные механизмы (fail2ban реже срабатывает, в логах меньше мусора, легче заметить аномалию). Именно в этой роли — вспомогательной, а не главной — смена порта оправдана.

Если вы разворачиваете сервер с нуля и хотите сразу настроить связку «ключи + правильный sshd_config» без блужданий по документации, у нас есть пошаговые инструкции под конкретные системы — например для Ubuntu 24.04: SSH-ключи вместо пароля на Ubuntu 24.04 — пошаговая установка. Там же разобраны частые ошибки при первом входе по ключу — они одинаковы что на 22, что на нестандартном порту.

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

Частые вопросы