Я заметил, что многие администраторы меняют порт ssh по умолчанию.
Есть ли разумная причина для этого?
Это не так полезно, как утверждают некоторые, но, по крайней мере, уменьшит влияние на ваши файлы журналов, поскольку многие попытки входа в систему методом грубой силы используют только порт по умолчанию, а не сканируют, чтобы увидеть, прослушивает ли SSH где-то еще. Некоторые атаки будут сканировать SSH где-то еще, так что это не лучшая пуля.
Если ваш сервер будет каким-то общим хостом, а не просто обслуживать потребности ваших проектов, использование нестандартного порта может быть проблемой, поскольку вам придется объяснять это своим пользователям снова и снова, и когда они забывают, и их клиентские программы не могут подключиться к порту 22!
Другая возможная проблема с SSH на нестандартном порте - это если вы столкнетесь с клиентом с ограничительным набором исходящих фильтров, который не может подключиться к вашему настраиваемому порту, потому что его фильтр разрешает только, например, порты 22, 53, 80. и 443, чтобы быть пунктом назначения для новых исходящих соединений. Это редкость, но, конечно, не редкость. По аналогичному вопросу некоторые интернет-провайдеры могут видеть зашифрованный трафик на порте, отличном от того, на котором он обычно ожидается (порт 443 или HTTPS, 22 для SSH и т. Д.), Как попытку скрыть P2P-соединение и ограничить (или заблокировать) соединение неудобным образом.
Я лично для удобства использую SSH на стандартном порте. Пока приняты обычные меры предосторожности (надежная политика паролей / ключей, ограничение входа в систему с правами root, ...), это не должно вызывать беспокойства, и проблема роста файла журнала, когда вы подвергаетесь атаке грубой силы, может быть уменьшена с помощью таких инструментов, как как fial2ban, чтобы временно заблокировать хосты, которые предоставляют слишком много неверных наборов учетных данных для аутентификации в заданный промежуток времени.
Какой бы порт вы ни выбрали, если вы откажетесь от 22, убедитесь, что он меньше 1024. В большинстве Unix-подобных настроек в их конфигурации по умолчанию только root (или пользователи в корневой группе) могут прослушивать порты ниже 1024, но любой пользователь может прослушивать более высокие порты. Запуск SSH на более высоком порту увеличивает вероятность того, что злоумышленник (или взломанный) сможет вывести из строя ваш демон SSH и заменить его своим собственным или прокси.
Это простая (но удивительно эффективная) форма безопасность через безвестность.
Если ваш SSH-сервер не подключен к порту 22, вероятность того, что его найдут те, кто сканирует весь Интернет в поисках слабых паролей для учетных записей по умолчанию, гораздо ниже. Если вы сканируете всю сеть, вы не можете позволить себе проверить все 64k возможных портов, чтобы найти SSH-сервер.
Однако, если кто-то активно нацеливается именно на вас, это не приносит никакой пользы, поскольку простой разовый nmap сканирование покажет порт, на котором он действительно работает.
Чтобы действительно избежать атак грубой силы, всегда важно выполнять несколько шагов:
Да, это полезно, потому что это просто помогает избежать всех атак грубой силы и помогает держать логи в чистоте :)
Что касается номера порта, который зависит от вас, я видел, что компании довольно часто используют 1291. Я использую что-то более высокое, чтобы избежать некоторых сценариев.
Запрет входа в систему root ssh и изменение номера порта и, возможно, что-то вроде fail2ban, и вы должны быть золотыми. добавьте iptables для хорошей меры и держите ваши данные в актуальном состоянии, и у вас не должно быть никаких проблем.
Делать это по какой-либо причине "безопасности" - подделка. Это лучший пример безопасности посредством неизвестности, которая не является безопасностью.
Если вы хотите, чтобы ваши журналы были немного светлее и чище, тогда да, это полезно, так как вы не получите столько попыток перебора портов / скрипта-kiddy.
Использование нестандартного порта ssh потребует дополнительных объяснений и документации, а также ответов на электронные письма «Я не могу войти в систему».
Считаю следующие преимущества запуска sshd на нестандартный порт важнее, чем проблемы, которые он создает:
Более того, если вы хотите быть действительно противным, вы всегда можете запустить поддельный sshd (с DenyUsers * ) на стандартном порту 22, в то время как ваш обычный sshd работает на порту 54321. Это даст вам уверенность в том, что все боты и подражатели злоумышленников будут вечно пытаться войти в службу, которая запрещает все входы в систему, потому что никому и в голову не придет попытаться найти ваш настоящий sshd сервис.
Мои 2 цента.
Я бы запустил ssh на стандартном порту и использовал бы что-то вроде fail2ban или запретить чтобы ограничить количество словарных атак.
Другой вариант - отключить вход с паролями altogheter и разрешить вход только с ssh-ключами.
Потому что есть много плохих людей, которые сканируют все IP-адреса серверов на наличие открытых портов в попытке использовать их. Раньше я атаковал свой SSH-порт в течение всего дня, пока не переместил его на другой порт и на IP-адрес, который больше не был связан ни с одним из моих веб-сайтов.
Это полезно в том смысле, что скрипт-боты, которые пытаются атаковать методом подбора пароля методом перебора, обычно сосредотачиваются на порту 22, поэтому изменение портов обычно сбрасывает их. Вам нужно будет сбалансировать ценность снижения этого риска с болью при настройке клиентов ssh для подключения к нестандартному порту (по общему признанию, не очень большая проблема, если у вас не так много пользователей).
В качестве альтернативы вы можете снизить риск грубой силы, отключив аутентификацию по паролю и потребовав вместо этого аутентификацию с ключом RSA.
Обычно я не меняю порт на SSHD, поэтому не могу предложить другой номер, но проверьте список часто используемых портов чтобы найти другой номер (то есть тот, который не используется чем-то другим и, следовательно, может быть отсканирован).
Я всегда меняю свой SSHd на порт 2222, это знают все, кому нужно попасть на мои серверы, и это не секрет. Это не принесет никакой выгоды в безопасности (если только потенциальный хакер не является абсолютным идиотом).
Единственная выгода Я понимаю, что в журнале аутентификации нет миллиона неудачных попыток входа в систему для root, alice, bob, sally, admin и т. Д.
Защита через скрытность оказалась бесполезной, обычно я настраиваю доступ ssh со стандартным портом по всем причинам, упомянутым выше (проблемы клиента при перенастройке, проблемы с брандмауэром и прокси и т. Д.).
В дополнение к этому я всегда отключаю аутентификацию по логину и паролю root и в качестве последнего шага использую fail2ban чтобы избавиться от надоедливых сообщений в системном журнале. В Debian / Ubuntu это так же просто, как набрать aptitude install fail2ban. Конфигурация по умолчанию работает довольно хорошо, но я обычно настраиваю некоторые параметры, чтобы они были более ограничительными, имея более длительное время блокировки (по крайней мере, один день) и только 2 неудачные попытки аутентификации как триггер для блокировки.
Если вы отключите парольный вход на свой сервер (что настоятельно рекомендуется), то изменение порта SSH будет совершенно бесполезным. Отключив вход в систему по паролю (и требуя аутентификации на основе ключей), вы устраняете возможность попыток подбора пароля, так что вы ничего не получите, возясь с номерами портов.
Если вы продолжите разрешать аутентификацию по базе паролей, то вы оставляете себя открытым для возможности успешной попытки грубой силы или, что более распространено, по моему опыту, ваш пароль будет скомпрометирован, потому что вы вводите его при использовании работающей системы кейлоггер.
Я бы сказал, что при смене порта SSH вы больше всего защищаете себя от автоматических сканирований, которые будут пытаться получить доступ, используя стандартные имена пользователей / пароли, если ваша политика паролей жесткая, вам не нужно беспокоиться о их.
Несмотря на то, что он выглядит как типичная «безопасность посредством неизвестности», я бы оценил его как имеющий смысл, поскольку сканирование всех возможных портов (~ 64 КБ) занимает гораздо больше времени, чем просто один из них.
Но могу добавить, что "стук порта" намного лучше.
Я использую SSH на порту> 1024 более 5 лет. С тех пор я не видел попыток сканирования портов в моем файле журнала (кроме как от себя). Есть мои серверы, которые я администрирую, и которые работают с портом> 1024.
Многие SSH-серверы, работающие на порту> 1024, имеют свои собственные веб-сайты, которые очень популярны.
Если SSH-сервер работает в моей компании, возможно, я уже разместил здесь IP-адрес этого сервера, чтобы вы, ребята, могли попытаться взломать сервер. К сожалению, SSH-сервер мне не принадлежит. ;-)
Но есть и другие вещи, которые вам придется настроить, чтобы сделать его безопасным. SSH> 1024 одного было бы недостаточно. Номер порта не должен быть в / etc / services, должен использоваться переадресация портов (например, порт 1124-> 22), прямой доступ к Root должен быть отключен и другие вещи.
Итак, если вы хотите поспорить, лучше запускайте SSH на порту> 1024 в течение нескольких лет.
п / с: 1124 это не мой SSH порт нет. Ха-ха.
Проблема в том, что брандмауэр настроен так, чтобы разрешать подключение только определенным IP-адресам, а босс устал открывать определенные IP-адреса, когда он на улице. Если вы блокируете определенные IP-адреса на брандмауэре, это может быть головной болью.
Я думаю о двух вещах. Смена порта защищает от автоматических атак. Вот и все, но это большая часть среднего атакующего трафика ... автоматические скрипты, сканирующие сети. Если вы измените порт по умолчанию, эти атаки сразу прекратятся. Так что в этом отношении есть смысл. Но он ничего не делает против направленной атаки, поскольку злоумышленник может просто сканировать из Nessus или NMAP, чтобы определить, какой порт (а) вы используете, если у вас есть особенный маленький друг, который вас достаточно ненавидит.
Во-вторых, если вы используете UNIX-подобные серверы, вы можете установить такую утилиту, как Denyhosts, чтобы остановить атаки. Если вы устанавливаете denyhosts, он отслеживает неправильные попытки входа в систему и после (вне зависимости от количества) неудачных попыток блокирует IP-адрес на указанный вами период времени. Denyhosts также может разговаривать с другими хостами denyhost и передавать списки запретов, поэтому, если злоумышленник окажется заблокированным в системе Linux Фреда в Монтане, ваша система также получит этот IP-адрес для блокировки. Очень полезно, если ваши пользователи помнят свои пароли.
Все зависит от ваших сценариев использования. Сколько у вас есть программ, которые являются «головной болью» для изменения порта подключения для SSH / SCP (и если они не позволяют этого или делают это затруднительным, вам действительно нужно подумать о смене поставщика лично). Если это всего лишь потенциальный страх, я бы сказал, что это не проблема. И это ваш босс, который просит кое-что, что не совсем дурацкое, поскольку многие системные администраторы меняют порт SSH (с некоторой критикой от людей, которые ненавидят все, что даже слабо пахнет безопасностью из-за неизвестности ... но это действительно сокращает грубый фоновый шум от автоматических сканирований.)
Сваривается - изменение порта блокирует автоматизированные скрипты и большую часть плохого трафика. Не остановит направленных нападающих. Подумайте также об установке утилиты автоматического запрета. Многослойная безопасность не повредит вам, если все сделано правильно, а смена портов помогает больше, чем в большинстве ситуаций.
Не ответ, но слишком длинный комментарий, поэтому я сделаю это CW.
Я некоторое время думал об этом и пришел к выводу, что в том, что говорит Джулиано в комментариях к ответу Альнитака, много правды. Тем не менее, я считаю, что запуск SSH на 22-м порту слишком упрощает запуск любых атак против него.
Чтобы решить эту проблему, я запускаю свои внутренние SSH-серверы на 22-м порту и использую брандмауэр для перенаправления высокого порта на 22-й порт на целевых машинах. Как указал Джулиано, это дает некоторую безопасность через неясность, сохраняя при этом безопасность низкого порта.
Я обычно не придерживаюсь принципа «безопасность через неясность», и часто отмечают, что простое сканирование порта обнаружит целевой порт, сделав неясность бесполезной. Чтобы решить эту проблему, мои брандмауэры (Smoothwall Express) как на работе, так и дома используют сценарий под названием Guardian Active Response, который запускается с помощью предупреждений Snort. Из наблюдений я могу сказать вам, что когда вы попадаете на более чем 3 разных порта из одного источника, ваши пакеты отбрасываются до заданного времени сброса. Это делает сканирование портов довольно трудным и занимает очень много времени, поэтому неясность действительно чего-то стоит. Фактически из-за этого меня так часто закрывали в прошлом, что я установил исключение для своего исходного (домашнего или офисного) IP-адреса. Конечно, злоумышленник может наткнуться на правильный порт в первый раз, но шансы на это против.
Смена порта ssh - бессмысленное занятие, которое дает вам лишь ограниченную безопасность. Лучше просто отключить аутентификацию по паролю, что устраняет риск попыток подбора пароля, и полагаться исключительно на аутентификацию на основе ключей ssh. Если в вашей среде требуется аутентификация по паролю, используйте какой-нибудь двухфакторный механизм, например SecurID или Wikid.
И то, и другое дает вам реальное повышение безопасности, тогда как изменение порта ssh создает только иллюзию безопасности.
Что ж, перенос SSH на другой порт имеет смысл, это помогает с безопасностью, но не сильно. Конечно, для этого вам необходимо контролировать свои брандмауэры, но это не проблема для вас. Что, как я считаю, сводит на нет преимущество перемещения порта, так это открытие допустимого диапазона - на самом деле я бы сказал, что это более чем сводит на нет пользу и подвергает вас большему риску, чем вы есть сегодня. Я уверен, что вы сможете убедить его как переместить порт, так и значительно уменьшить входящий диапазон, сопоставив список вероятных точек входа вместо того, чтобы просто открывать их все.
я думаю, если вы еще не открыли порт, который может оказаться удобным, иначе нет.
Это практическая точка зрения: я управлял общедоступными частными серверами ssh более четырех лет с измененным портом SSH, и у меня не было ни одной попытки сканирования пароля. Ради этого QA я только что активировал 22 на одном из них на один день. В результате меня сканировали примерно каждые 10 минут с частотой попыток ввода пароля около 5 в секунду. Более того, «детки сканирования» также ищут серверы с определенными уязвимостями OpenSSH.
Наверняка это безопасность неизвестностью что не поможет, если у вас есть враг.
Он отлично работает, несмотря на нытье толпы «безопасность через безвестность».
Глупые кролики, ВСЯ безопасность - это безопасность через неизвестность. Просто потому, что вы считаете, что непонятный криптопротокол Z [требующий комбинации образцов ДНК, общих ключей и невозможности ввода паролей людьми] на самом деле безопасен, не делает это так. По правде говоря, любая мера безопасности зависит от вероятностей и предположений пользователей. Жалко для вас, если я знаю, как использовать это предположение, но вот оно.
Тем не мение,
Мы делали это в течение многих лет вместе с а) ограничением скорости попыток подключения (однако я не знаю, как мы это установили, что-то в конфигурации ssh) и б) скриптом для запрета любого хоста, выполняющего атаку по словарю с более X ошибочных предположений за Y минут. Мы запрещаем хосту устанавливать соединение на определенный период времени, и это упрощает адаптацию к изменяющейся топологии сетей.
Если ваши пароли достаточно сложные, и они могут сделать только 3 попытки за 15 минут, нечего опасаться. Также нетрудно наблюдать за распределенными атаками - мы обычно сопоставляем по подсети и IP, чтобы исключить подобные вещи.
Наконец, все, что вам нужно, это какой-то секретный метод белка, чтобы разрешить подключения к вашему порту путем изменения правил f / w. Это может быть что угодно ... smtp, web, magic dns-запросы. Такие вещи, как SecurID или Wikid, просто передают дополнительную информацию третьим лицам. И не заставляйте меня запускать безопасные сертификаты от третьих лиц.