Ответы:
Наиболее вероятная причина состоит в том, чтобы усложнить людям, пытающимся случайным образом взломать любой логин SSH, который они могут найти. Мой компьютер, подключенный к Интернету, использует порт SSH по умолчанию, и мои журналы раньше заполнялись такими вещами (взяты из реального файла журнала):
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
В настоящее время я использую DenyHosts для блокировки IP-адресов, которые не могут аутентифицироваться слишком много раз, но, вероятно, так же просто переключать порты; практически все подобные атаки не будут беспокоить сканирование, чтобы увидеть, слушает ли ваш sshd другой порт, они просто предполагают, что вы его не используете, и продолжаете
Нет, это тактика безопасности .
Если ваша настройка sshd не подходит для того, чтобы сталкиваться с глупыми сценаристами, пытающимися использовать только порт 22, у вас все равно есть проблема.
Более рациональной реакцией будет:
Некоторые люди также могут быть раздражены шумом, который sshd записывает в системный журнал, например:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
Тогда может возникнуть соблазн замаскировать порт sshd или использовать решение для автоматической блокировки (например, DenyHosts, Fail2ban или BlockHosts), чтобы снова увеличить отношение сигнал / шум .
Но лучшие альтернативы существуют. Например, вы можете настроить демон syslog таким образом, чтобы шум журнала sshd записывался только, скажем, /var/log/sshd-attempts.log
а сигнал (т. Е. Оставшиеся сообщения журнала sshd) записывался и /var/log/messages
т. Д., Как и раньше.
Развертывание автоматических инструментов блокировки следует рассматривать с осторожностью , поскольку добавление больше сложности с обеспечением безопасности соответствующих систем означает также увеличение риска в эксплуатации . И действительно, за эти годы существует несколько отчетов об уязвимостях DoS для каждого DenyHosts , Fail2ban и BlockHosts .
Смена порта SSH - это в основном театр безопасности . Это дает вам нечеткое чувство, что вы что-то сделали. Вы спрятали порт SSH под ковриком.
Если вы запустите SSH-сервер в Интернете, вы увидите много неудачных попыток входа в систему в своих журналах, от ботов, которые ищут тупо слабые пароли, слабые ключи и известные эксплойты в старых версиях сервера. Неудачные попытки - это просто неудачные попытки. Что касается оценки вашей уязвимости, они совершенно не имеют значения. Вам нужно беспокоиться об успешных попытках вторжения, и вы не увидите их в своих журналах.
Изменение порта по умолчанию уменьшит число попаданий таких ботов, но это только мешает наименее искушенным злоумышленникам, которых останавливает какой-либо достойный уровень безопасности (регулярно применяются обновления безопасности, достаточно надежные пароли или отключенная аутентификация паролей). Единственным преимуществом является уменьшение объема бревен. Если это проблема, рассмотрите что-то вроде Denyhosts или Fail2ban, чтобы ограничить скорость соединения, это также пойдет на пользу вашей пропускной способности.
Изменение порта по умолчанию имеет существенный недостаток: это снижает вероятность входа в систему из-за брандмауэра. Межсетевые экраны с большей вероятностью пропускают сервисы через порт по умолчанию, чем через какой-либо другой случайный порт. Если вы не используете HTTPS-сервер, подумайте о том, чтобы заставить SSH также прослушивать порт 443 (или перенаправлять входящие TCP-запросы с порта 443 на порт 22), поскольку некоторые брандмауэры разрешают трафик, который они не могут декодировать, на порту 443, поскольку он выглядит как HTTPS.