Почему SSH имеет незащищенные дефолты?

Почему SSH поставляется с такой незащищенной конфигурацией по умолчанию?

чтобы назвать то, что я считаю необеспеченными дефолтами:

  • вход root включен в SSH
  • Протокол SSH версии 1 (который уязвим для атак MIM) разрешен

Там также нет встроенного механизма для обработки грубых forceattacks

Я понимаю, что интероперабельность и совместимость важны для новой системы, но установка сервера в сети с этими значениями по умолчанию является серьезной проблемой безопасности. Если кто-то не знал об этих параметрах конфигурации, они могли бы поставить сервер в живую, который очень уязвим для того, чтобы быть грубым, и не знать проблемы, достаточно долго для того, чтобы кто-то мог получить доступ.

Идея грубого корня на SSH существует уже давно, и существует постоянный «фоновый шум» попыток входа в систему на любом сервере из ботов и т. П. Было бы разумно отправить SSH с некоторыми значениями по умолчанию, которые помогли бы смягчить эту угрозу.

В чем причина этих незащищенных дефолтов?

Во многих системах ваша единственная точка входа в систему – через ssh. При новой установке без создания учетной записи пользователя единственная учетная запись, которую вы можете иметь, – root.
Тогда даже если у вас несколько учетных записей, что делать, если вы используете внешнюю аутентификацию, а ваша система аутентификации терпит неудачу. Вы должны быть в состоянии вернуться в коробку и исправить ее.

Вы можете установить PermitRootLogin without-password чтобы работать только с ssh-ключами, но для этого вам нужно войти хотя бы один раз с паролем, чтобы добавить ssh-ключ.

Помимо того, почему это может потребоваться на начальном этапе, я бы сказал, что обязанность сопровождающего пакета сделать дефолты разумно безопасными, но все же функциональными. Обеспечение безопасности по мере того, как это было возможно, это такие вещи, как отключить root, заставить его прослушивать порт, отличный от 22, отключить аутентификацию паролей и т. Д. Выход из корневого ssh с включенным паролем не является самозащитой. Это только дыра в безопасности, если у root есть слабый пароль.
Я бы сравнил это с политикой брандмауэра. Большинство дистрибутивов отправляются без использования правил iptables или настройки sysctl. Внесение сервера в Интернет без какой-либо настройки является значительным риском. Владелец сервера должен выполнить политику безопасности, которая подходит для цели сервера.

Ваше распределение является наиболее вероятной причиной для этих небезопасных значений по умолчанию. В разных дистрибутивах используются разные конфигурации по умолчанию.

С другой стороны, неплохо было бы начать сетевую услугу без предварительной настройки. Админы, как правило, имеют свои особые потребности и, по крайней мере, смотрят на конфигурацию после установки, если не отправляют свои собственные скрипты.

Атаки с применением грубой силы: Существуют другие способы обнаружения таких атак. Такие, как ipsets и брандмауэры или даже системы обнаружения вторжений. Не нужно ssh придумывать собственное решение.

SSH не имеет неустойчивых значений по умолчанию (по крайней мере, не те, о которых вы упоминаете).

Протокол 1 отключен по умолчанию с OpenBSD 4.7 (выпущен в 2010 году). Даже когда протокол 1 по-прежнему включен по умолчанию, он использовался бы только в том случае, если клиент запросил его, а клиент (например, я думаю, что все клиенты, поддерживающие протокол версии 2) использует протокол версии 2, если сервер не поддерживает его или пользователь явно запросил версию 1 (а с OpenBSD 4.7 клиент OpenSSH не возвращается к протоколу версии 1 явно).

Разрешение входа root из SSH не является проблемой безопасности. Если он разрешает путь атаки, это означает, что администратор сервера сделал плохую работу. Не выбирайте допустимый пароль root! Отключение корневых логов упрочняется – это безопасность в глубину. Это повышает уровень безопасности, добавляя уровень защиты, если пользователь совершает ошибку. Это хорошо, но это не требуется.

Если вы не выбираете глупо угаданные пароли, то единственной угрозой, которую требуется для постоянной попытки входа¹, является заполнение вашего раздела журнала.

Дросселирование скорости попыток входа – это обоюдоострый меч. С одной стороны, это снижает риск того, что злоумышленники угадают слишком простой пароль и уменьшит пропускную способность, которую они потребляют. С другой стороны, если вам необходимо войти на ваш сервер из того же сетевого окружения, что и злоумышленник, и вы установили строгие ограничения, у вас будет DoS'ed.

¹ Не просто попытки входа в root , кстати. Также используются общие имена и общие имена системных учетных записей, такие как admin , webmaster и т. Д.