Это не так полезно, как утверждают некоторые люди, но, по крайней мере, оно уменьшит влияние на ваши файлы журналов, так как многие попытки входа в систему грубой силы используют только порт по умолчанию, а не сканирование, чтобы увидеть, прослушивает ли SSH где-либо еще. Некоторые атаки сканируют SSH в других местах, поэтому это не серебряная пуля.
Если ваш сервер будет каким-то общим хостом, вместо того, чтобы просто обслуживать потребности ваших проектов, использование порта не по умолчанию может быть проблемой, так как вам придется объяснять это своим пользователям снова и снова и снова, и когда они забывают и их клиентские программы не могут подключиться к порту 22!
Другая возможная проблема с SSH на нестандартном порту - это если вы сталкиваетесь с клиентом с ограниченным набором исходящих фильтров, который не может подключиться к вашему пользовательскому порту, потому что их фильтр допускает, например, только порты 22, 53, 80. и 443, чтобы быть пунктом назначения для новых исходящих соединений. Это необычно, но, конечно, не случайно. По аналогичному вопросу некоторые интернет-провайдеры могут рассматривать зашифрованный трафик на порте, отличном от того, где он обычно ожидается (порт 443 или HTTPS, 22 для SSH и т. Д.), В качестве попытки скрыть соединение P2P и газ (или блокировать). соединение в неудобной манере.
Я лично держу SSH на стандартном порте для удобства. До тех пор, пока принимаются обычные меры предосторожности (строгая политика паролей / ключей, ограничение корневых входов в систему, ...), это не должно вызывать беспокойства, и проблема роста файла журнала, когда вы подвергаетесь атаке методом перебора, может быть смягчена с помощью таких инструментов, как как fial2ban для временной блокировки хостов, которые выдают слишком много неверных наборов учетных данных для аутентификации в данный промежуток времени.
Какой бы порт вы ни выбрали, если вы отойдете от 22, убедитесь, что он ниже 1024. При большинстве настроек Unix-a в их конфигурации по умолчанию только root (или пользователи в корневой группе) могут прослушивать порты ниже 1024, но любой пользователь может прослушивать порты более высокого уровня. Запуск SSH на более высоком порту повышает вероятность того, что мошеннический (или взломанный) пользователь сможет сломать ваш демон SSH и заменить его собственным или прокси-сервером.
Я единственный пользователь этого сервера. Спасибо за разъяснение проблемы 1024+. Я бы использовал порт 48ххх, если бы выбрал. Во всяком случае, на данный момент я до сих пор не понимаю, полезно это или нет = /
динамически
16
+1 для> 1024 бит.
MattC
26
Это простая (но удивительно эффективная) форма безопасности через неизвестность .
Если ваш SSH-сервер не подключен к порту 22, его гораздо меньше найдут те, кто сканирует весь интернет в поисках слабых паролей для учетных записей по умолчанию. Если вы сканируете всю сеть, вы не можете позволить себе проверить все 64 тыс. Возможных портов, чтобы найти SSH-сервер.
Однако, если кто-то конкретно на вас целится, это не дает никаких преимуществ, поскольку простое одноразовое nmapсканирование покажет порт, на котором он фактически работает.
"проверить все 64k возможных портов" ... Запуск SSH на любом порту выше 1023 является просто неправильным. Это делает систему более уязвимой, чем оставить ее работающей в порте по умолчанию.
Джулиано
3
@ Джулиано - объясни, пожалуйста. Только потому, что для прослушивания на привилегированном порту вы должны быть пользователем root, это не делает небезопасным запуск на непривилегированном порту.
Альнитак
4
Кстати, это не безопасность из-за неясности, в противном случае вам также придется вызывать аутентификацию по паролю. Безопасность через неизвестность - это когда реализация не раскрывается. Здесь реализация четко указана (это «Я изменил сервисный порт»), а секрет («какой порт?») Остается секретным.
Джулиано
5
@ Джон - на самом деле я понимаю точку зрения Джулиано. Это не делает самого демона SSH менее безопасным, но в общем случае работа на непривилегированном порте лишает нас нормального предположения, что root запустил демон. Поэтому, если вы можете каким-то образом остановить этого демона (например, выполнив DoSing), вы можете запустить своего собственного фальшивого демона на его месте без использования root-эксплойта. Этот поддельный демон может затем собрать достаточно деталей, чтобы позволить дальнейшие эксплойты.
Альнитак
2
@Джон, это правда - он все еще требует, чтобы злоумышленник получил достаточный доступ для запуска нового демона. Ключевым моментом является то, что им больше не нужен root- доступ для запуска.
Альнитак
21
Чтобы действительно избежать атак грубой силы, всегда важно выполнить несколько шагов:
Установите denyhosts или fail2ban
Ограничить количество подключений в секунду по порту ssh
Похоже, хороший список, за исключением части смены порта, с которой я не совсем согласен, это слишком много неясности. В любом случае современный сканер портов найдет его за несколько секунд? (и многие сети не пропускают случайный портовый трафик, обычно ограниченный, скажем, 22, 80 и 443)
Оскар Дюверборн
1
Атаки с использованием перебора портов с помощью перебора, который проверяет, работает ли ssh на порте по умолчанию, хорошо, если атака более серьезная, только в этом случае злоумышленник может выполнить сканирование дырочных портов в вашей сети / хостах.
Али Мезгани
1
На самом деле, я думаю, что за хорошим брандмауэром, если вы обновляете свои сервисы и меняете их настройки по умолчанию, вы можете быть защищены от атак злоумышленников. и может быть не от 0дней подвигов или неизвестных атак
Али Мезгани
2
Использование denyhosts / fail2ban уменьшает необходимость переключения портов или использования ключей. Если вы не разрешаете пароли, то нет смысла использовать denyhosts / fail2ban или менять порты.
Джереми Л
1
Использование denyhosts / fail2ban не обязательно снижает потребность в дополнительных мерах безопасности. Главное в безопасности - создать как можно больше препятствий для пользователей, которые пытаются обойти безопасность. Конечно, вам, вероятно, не нужно менять порт с 22 на 2222, но скажите, что придет другой администратор и повторно активирует пароль ... у вас все еще будет несколько других скачков скорости. Каждый шаг, указанный выше, дает администратору процент, близкий к невозможности 100% безопасности.
Патрик Р
12
Да, это полезно, так как оно помогает избежать всех атак грубой силы и помогает сохранять чистоту журналов :)
Что касается номера порта, который зависит от вас, я видел, что компании довольно часто используют 1291. Я использую что-то более высокое, чтобы избежать некоторых сценариев.
Если вы не разрешаете вход в систему через root ssh и не меняете номер порта и, возможно, что-то вроде fail2ban, вы должны быть честны. добавьте iptables для правильной оценки и держите ваши вещи в актуальном состоянии, и у вас не должно быть никаких проблем.
Но посмотрите на ответ Дэвида Спиллета, чтобы узнать, почему порт 1291 (больше 1024) может быть опасным.
Конерак
Если вы собираетесь посоветовать использовать непривилегированный порт через 2 года после множества других, более хороших ответов - возможно, подготовьте более вескую причину, чем «я видел, как компании это делают». Я видел, как компании делают много вещей. Я редко хочу последовать их примеру.
underscore_d
11
Использование нестандартного порта ssh потребовало бы большего объяснения и документации, а также ответов на электронные письма «Я не могу войти».
Я считаю следующие преимущества запуска sshd на нестандартном порту более важными, чем проблемы, которые он создает:
99,9999% атак методом "грубой силы" выполняют боты, которые ищут только порт 22 и никогда не тратят время на поиск нестандартного порта. Атаки грубой силой и контрмеры, такие как denyhosts или fail2ban, потребляют ресурсы, которые вы сэкономите, просто запустив сервер ssh на нестандартном порту.
Вы избавитесь от всех бесполезных отчетов о ботах, пытающихся проникнуть в вашу систему. Если какой-либо IP-адрес обнаруживается в отчете о неудачных входах, скорее всего, это человек.
Более того, если вы хотите быть действительно противным, вы всегда можете запустить поддельный sshd (с DenyUsers * ) на стандартном порту 22, в то время как ваш обычный sshd работает на порту 54321. Это гарантирует, что все боты и злоумышленники-нарушители будут работать вечно попробуйте войти в службу, которая запрещает все входы в систему, потому что никто никогда не подумает о том, чтобы попытаться найти вашу настоящую службу sshd.
Это может привести к еще большему количеству обращений в службу поддержки.
Брэд Гилберт
3
Это правда, но повышенная безопасность имеет свою цену. :)
Born To Ride
11
Делать это по любой причине "безопасности" - фальшивка. Это лучший пример безопасности по неизвестности, которая не является безопасностью.
Если вы хотите, чтобы ваши журналы были немного легче и чище, тогда да, это полезно, так как вы не будете получать так много попыток стучать в порт / script-kiddy bruteforce.
Ага. Когда у меня был ssh на порту 22, у меня было более 20000 неудачных попыток ввода пароля в моих журналах в день. Это означало, что я получаю электронное письмо с предупреждением каждый день. У меня была отключена аутентификация по паролю - у вас должен был быть правильный закрытый ключ для входа в систему - поэтому я не беспокоился о том, что кто-то может войти, но я предпочел бы получать электронные письма с предупреждением о безопасности только тогда, когда происходит что-то реальное.
2010 года
10
Я бы запустил 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, это автоматическое сканирование, которое попытается получить доступ с использованием стандартных имен пользователей и паролей. Если ваши политики паролей жесткие, вам не нужно беспокоиться о их.
не говоря уже о том, что сканер портов будет пробовать и другие порты.
Джим Девил
4
Если вы отключите вход с паролем на свой сервер (что настоятельно рекомендуется), то изменение порта SSH совершенно бесполезно. Отключая логин с паролями (и требуя аутентификацию на основе ключей), вы исключаете возможность попыток перебора паролей, так что вы ничего не получаете, суетясь с номерами портов.
Если вы продолжаете разрешать проверку подлинности на основе пароля, то вы оставляете себя открытым для возможности успешной попытки перебора или, как мне показалось, более распространенным - ваш пароль был взломан, потому что вы вводите его при использовании работающей системы кейлоггер.
Если вы / абсолютно бесполезны / совершенно бесполезны для безопасности /, я бы согласился. Однако изменение порта полезно для подавления шума в журнале аутентификации.
Крис С
"и требует аутентификации на основе ключей"? что это
динамический
1
@ yes123, SSH может использовать пары открытого и закрытого ключей для аутентификации пользователя вместо пароля. Их пара ключей также может быть защищена паролем, предлагая двухфакторную аутентификацию (что-то, что вы знаете = пароль; что-то, что у вас есть = файл ключа). Если вы реализуете это, вы можете отключить логин паролей (таким образом, кто-то, кто знает ваш локальный пароль, не сможет получить доступ к файлу ключа и паролю файла ключа). Пароли относительно небезопасны по сравнению с ключами, в миллионы раз проще перебором, чем пары ключей (хотя обычно все еще сложно). Смотрите man ssh-keygenмного информации.
Крис С
@ yes123, различные справочные страницы, связанные с ssh (sshd, sshd_config, ssh, ssh_config) полезны для чтения. Этот документ выглядит как хорошее руководство по аутентификации с открытым ключом с помощью ssh.
Жаворонки
2
Несмотря на то, что я выгляжу как типичная «безопасность по неизвестности», я бы оценил ее как имеющую смысл, поскольку сканирование всех возможных портов (~ 64 КБ) требует гораздо больше времени, чем один из них.
Но могу добавить, что «стук в порт» гораздо лучше.
Не ответ, но слишком долго для комментария, поэтому я сделаю это CW.
Я думал об этом некоторое время и пришел к выводу, что в том, что говорит Джулиано в комментариях к ответу Альнитак, есть много правды. Тем не менее, я считаю, что использование SSH на порту 22 делает слишком простым запуск любых атак против него.
Чтобы решить эту проблему, я запускаю свои внутренние SSH-серверы на порту 22 и использую брандмауэр для переноса высокого порта на 22 на целевые машины. Это дает некоторую безопасность через неизвестность, сохраняя при этом безопасность низкого порта, как указывал Джулиано.
Безопасность через неизвестность - это не тот принцип, на который я обычно подписываюсь, и часто отмечается, что простое сканирование портов покажет целевой порт, делая затенение бесполезным. Чтобы решить эту проблему, мои брандмауэры (Smoothwall Express), как на работе, так и дома, используют скрипт под названием Guardian Active Response, который запускается оповещениями Snort. Из наблюдений я могу сказать, что когда вы подключаетесь к более чем 3 различным портам из одного источника, ваши пакеты отбрасываются до установленного времени сброса. Это делает довольно сложным и чрезвычайно трудоемким запуск сканирования портов, что делает затенение действительно чего-то стоящим. На самом деле это заставляло меня так часто отключаться в прошлом, что я установил исключение для своего IP-адреса источника (дома или в офисе).
Хорошая идея с портом вперед, Джон! Я думаю, что мы оба чему-то научились :)
Альнитак
1
Проблема, с которой вы столкнулись, заключается в том, что брандмауэр настроен так, что позволяет подключаться только определенным 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 в течение нескольких лет.
Хорошо перенести 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, просто передают больше информации третьим лицам. И не заводите меня на безопасные сертификаты через третьих лиц.
-1, ты, кажется, не совсем понимаешь, что такое мрак ... Создание чего-то неочевидного - это не то же самое, что наложение блокировки на него. Хотя верно и то, что никакая безопасность не является абсолютной, безусловно, есть различия, и смешанная трехфакторная аутентификация в неизвестности никому не поможет.
Крис С
1
Извини, Крис, это религия культа грузов. Может быть, вы не можете взломать замок, и, следовательно, думаете, что его можно защитить, но можно взломать все замки. Думайте нестандартно: во многих случаях создание чего-то «неочевидного» может быть лучше, чем использование блокировки. Ваша модель / представление о безопасности подобна тому, как вы оставляете свой ноутбук в запертом автомобиле с установленным сигналом тревоги - один твикер с камнем и ваш ноутбук исчезает. Но, возможно, это не твикер, а кто-то с 0-дневным подвигом и временем, чтобы убить ... О, смотри! У Криса есть «безопасная» и вполне видимая цель! Непрозрачность является ОЧЕНЬ важной частью безопасности.
случайно Джо
Извините, но ваши сравнения и логика не выдерживают. Я умею взламывать замки, быстрее их отрезать, разбить окно, обойти. Каждая мера безопасности требует определенного количества времени и усилий, чтобы ее обойти; Мрак не занимает много времени и усилий, от нескольких минут до нескольких часов. Настоящая безопасность, например попытки пароля с ограничением скорости, заставляют проходить через пароль значительное количество времени. Это существенное временное несоответствие - это разница между «фальшивой» безопасностью и «реальной»; мрак падает в первом.
Ответы:
Это не так полезно, как утверждают некоторые люди, но, по крайней мере, оно уменьшит влияние на ваши файлы журналов, так как многие попытки входа в систему грубой силы используют только порт по умолчанию, а не сканирование, чтобы увидеть, прослушивает ли 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 для правильной оценки и держите ваши вещи в актуальном состоянии, и у вас не должно быть никаких проблем.
источник
Я считаю следующие преимущества запуска 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
много информации.Несмотря на то, что я выгляжу как типичная «безопасность по неизвестности», я бы оценил ее как имеющую смысл, поскольку сканирование всех возможных портов (~ 64 КБ) требует гораздо больше времени, чем один из них.
Но могу добавить, что «стук в порт» гораздо лучше.
источник
Не ответ, но слишком долго для комментария, поэтому я сделаю это 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, просто передают больше информации третьим лицам. И не заводите меня на безопасные сертификаты через третьих лиц.
источник