Наиболее вероятная причина состоит в том, чтобы усложнить людям, пытающимся случайным образом взломать любой логин 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, у вас все равно есть проблема.
Более рациональной реакцией будет:
убедитесь, что ваши пользователи используют надежные пароли, которые трудно угадать
отключите аутентификацию по паролю (по крайней мере, для важных учетных записей) и просто используйте аутентификацию с открытым ключом
следите за ssh-безопасными проблемами и обновлениями
Некоторые люди также могут быть раздражены шумом, который 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 .
Я не совсем согласен с тем, что «это безопасность по неизвестности», я думаю, что этот ответ является распространенной ошибкой в данном случае. Рассуждения Майкла, как правило, показывают, что это лучшая причина, чтобы иметь это в другом месте Это в основном просто для того, чтобы избавиться от всех скриптовых бот-атак. Это не обязательно означает, что вы их боитесь или считаете эффективным против решительного злоумышленника. Я знаю, что никогда не волновался, что они действительно войдут. Но вся сруба была раздражающей.
ксенотеррацид
1
@xenoterracide: Если вас беспокоит только удобочитаемость ваших файлов журналов, то есть другие лучшие альтернативы, чтобы исключить шум, вместо того, чтобы менять порт в качестве тактики неясности, что и было вопросом. Относительно блокировки IP, которая не была частью вопроса: пожалуйста, обратите внимание, что добавление большей сложности к системам, относящимся к безопасности, также увеличивает риск эксплуатации. Рассмотрим, например, seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Да, на DenyHosts это повлияло.
maxschlepzig
1
В уме есть нечто большее, чем просто читабельность. Правильно задокументированное изменение порта не является безопасностью по незаметности.
ксенотеррацид
4
Смена порта SSH - это в основном театр безопасности . Это дает вам нечеткое чувство, что вы что-то сделали. Вы спрятали порт SSH под ковриком.
Если вы запустите SSH-сервер в Интернете, вы увидите много неудачных попыток входа в систему в своих журналах, от ботов, которые ищут тупо слабые пароли, слабые ключи и известные эксплойты в старых версиях сервера. Неудачные попытки - это просто неудачные попытки. Что касается оценки вашей уязвимости, они совершенно не имеют значения. Вам нужно беспокоиться об успешных попытках вторжения, и вы не увидите их в своих журналах.
Изменение порта по умолчанию уменьшит число попаданий таких ботов, но это только мешает наименее искушенным злоумышленникам, которых останавливает какой-либо достойный уровень безопасности (регулярно применяются обновления безопасности, достаточно надежные пароли или отключенная аутентификация паролей). Единственным преимуществом является уменьшение объема бревен. Если это проблема, рассмотрите что-то вроде Denyhosts или Fail2ban, чтобы ограничить скорость соединения, это также пойдет на пользу вашей пропускной способности.
Изменение порта по умолчанию имеет существенный недостаток: это снижает вероятность входа в систему из-за брандмауэра. Межсетевые экраны с большей вероятностью пропускают сервисы через порт по умолчанию, чем через какой-либо другой случайный порт. Если вы не используете HTTPS-сервер, подумайте о том, чтобы заставить SSH также прослушивать порт 443 (или перенаправлять входящие TCP-запросы с порта 443 на порт 22), поскольку некоторые брандмауэры разрешают трафик, который они не могут декодировать, на порту 443, поскольку он выглядит как HTTPS.
Ответы:
Наиболее вероятная причина состоит в том, чтобы усложнить людям, пытающимся случайным образом взломать любой логин SSH, который они могут найти. Мой компьютер, подключенный к Интернету, использует порт SSH по умолчанию, и мои журналы раньше заполнялись такими вещами (взяты из реального файла журнала):
В настоящее время я использую DenyHosts для блокировки IP-адресов, которые не могут аутентифицироваться слишком много раз, но, вероятно, так же просто переключать порты; практически все подобные атаки не будут беспокоить сканирование, чтобы увидеть, слушает ли ваш sshd другой порт, они просто предполагают, что вы его не используете, и продолжаете
источник
Нет, это тактика безопасности .
Если ваша настройка sshd не подходит для того, чтобы сталкиваться с глупыми сценаристами, пытающимися использовать только порт 22, у вас все равно есть проблема.
Более рациональной реакцией будет:
Некоторые люди также могут быть раздражены шумом, который sshd записывает в системный журнал, например:
Тогда может возникнуть соблазн замаскировать порт 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.
источник