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