Почему root-вход через SSH настолько плох, что всем советуют его отключить?

83

Все в Интернете советуют отключить root-вход через SSH, так как это плохая практика и дыра в безопасности системы, но никто не объясняет, почему это так.

Что такого опасного в том, чтобы включить root-вход (особенно при отключенном парольном входе)?

И в чем разница между именем пользователя X и паролем Y или корневым именем пользователя и паролем X + Y с точки зрения безопасности в случае, если разрешена аутентификация по паролю?

ssh security root

— порыв
источник

2

Наличие пользователя root в большинстве систем само по себе плохо, оставьте в покое доступ к SSH для указанного пользователя!

— Суман

1

Для ehealth-aussie.blogspot.com/2012/01/… необходима root-регистрация через ssh . Все это компромисс.

— Эмори

2

Хм ... мы должны перенести этот вопрос в безопасность? Поскольку тема больше ориентирована на безопасность, чем на * nix системы.

— Брайам

1

Есть административная причина для отключения root. На коммерческих серверах вы всегда хотите контролировать доступ лично. корень никогда не человек. Даже если вы разрешаете некоторым пользователям иметь root-доступ, вы должны заставить их войти в систему через своего собственного пользователя, а затем su -или sudo -iоколо того, чтобы их фактический вход был зарегистрирован. Это значительно упрощает аннулирование любого доступа к пользователю, так что даже если у него есть пароль root, он ничего не сможет с ним сделать.

— Филипп Коулинг

62

Почему рут над SSH плох

Есть много ботов, которые пытаются войти в ваш компьютер через SSH. Эти боты работают следующим образом.

Они выполняют что-то вроде, ssh root@$IPа затем они пробуют стандартные пароли, такие как «root» или «password123». Они делают это так долго, как могут, пока не найдут правильный пароль. На всемирно доступном сервере вы можете увидеть множество записей в ваших файлах журналов. Я могу идти до 20 в минуту или больше.

Когда злоумышленникам повезет (или хватит времени), и они найдут пароль, у них будет root-доступ, и это будет означать, что у вас проблемы.

Но когда вы не разрешаете root входить через SSH, бот должен сначала угадать имя пользователя, а затем соответствующий пароль. Допустим, список правдоподобных паролей содержит Nзаписи, а список вероятных пользователей - Mбольшие записи. У бота есть набор N*Mзаписей для тестирования, так что это немного усложняет бот по сравнению с корневым случаем, когда он имеет только набор размеров N.

Некоторые люди скажут, что это дополнительное Mне реальное повышение безопасности, и я согласен, что это лишь небольшое улучшение безопасности. Но я думаю об этом больше как об этих маленьких замках, которые сами по себе небезопасны, но они мешают многим людям легко получить доступ. Это, конечно, допустимо только в том случае, если на вашем компьютере нет других стандартных имен пользователей, таких как tor или apache.

Лучшая причина запрета root - это то, что root может нанести гораздо больший урон машине, чем обычный пользователь. Таким образом, если по счастливой случайности они найдут ваш пароль, вся система будет потеряна, в то время как со стандартной учетной записью пользователя вы сможете манипулировать только файлами этого пользователя (что все еще очень плохо).

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

В заключение я бы сказал, что не имеет значения, какой пароль пользователя получает злоумышленник. Когда они угадывают один пароль, вы больше не можете доверять системе. Злоумышленник может использовать права этого пользователя для выполнения команд sudo, злоумышленник также может использовать уязвимость в вашей системе и получить права root. Если у злоумышленника был доступ к вашей системе, вы больше не можете ему доверять.

Здесь следует помнить, что каждый пользователь в вашей системе, которому разрешено входить через SSH, является дополнительным недостатком. Отключая root, вы устраняете одну очевидную слабость.

Почему пароли через SSH плохие

Причина отключения паролей действительно проста.

Пользователи выбирают плохие пароли!

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

Кроме того, пользователи часто используют свои пароли для входа в Facebook или в свои учетные записи Gmail и на ваш сервер. Поэтому, когда хакер получает пароль учетной записи этого пользователя Facebook, он может попасть на ваш сервер. Пользователь может легко потерять его из-за фишинга, иначе сервер Facebook может быть взломан.

Но когда вы используете сертификат для входа в систему, пользователь не выбирает свой пароль. Сертификат основан на случайной строке, которая очень длинная от 1024 до 4096 бит (пароль ~ 128 - 512 символов). Кроме того, этот сертификат предназначен только для входа на ваш сервер и не используется никакими внешними сервисами.

связи

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

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

— Рафаэль Аренс
источник

10

Хорошее резюме. Но ssh приватные ключи тоже могут быть украдены.

— Фахим Митха

16

@Faheem Mitha Да, но украденный отличается от угаданного, что делают боты. Кроме того, ваш закрытый ключ находится только в ваших руках (или на жестком диске), а не в руках третьих лиц, таких как Stack Exchange или Google.

— Рафаэль Аренс

2

+1. Этот ответ может на самом деле сводиться к просто N*M > N. Поскольку на большинстве хостов * nix есть rootпользователь, если вы разрешите root входить напрямую с удаленного хоста, размер тестовой матрицы равен количеству паролей, которые нужно попробовать; Запрещение прямого входа в систему root, количество возможных комбинаций умножается на количество имен пользователей, которые вы хотите проверить (и все еще нет гарантии, что вы будете проверять действительные имена пользователей!).

— CVn

3

@ MichaelKjörling Я бы добавил, что получить имя пользователя несложно, поскольку обычно имя пользователя не является секретом, и я, возможно, мог бы попросить кого-нибудь получить его. Но это помогает против ботов и простых попыток.

— Рафаэль Аренс

2

@ Каждый, если в имени пользователя есть символы X и пароль Y, есть # of X length words* # of Y length wordsвозможные комбинации, которые можно попробовать. Когда имя пользователя фиксированное (например, root), но пароль имеет длину X + Y символов, # of X+Y length wordsвозможны пароли. И # of X+Y length words=# of X length words * # of Y length words

— скарап

10

Это может быть одной из причин, по которой прямой вход в систему root запрещен.

Попытки грубой силы. Прямой вход в систему root может привести к большему ущербу при успешной атаке грубой силы.
Неправильная конфигурация SSH-ключей без пароля (возникает ошибка человека) может привести к тому, что ваша машина будет подключена к Интернету.

Но это всего лишь СОВЕТ айсберга. Вам необходимо настроить другие ограничения и конфигурации, такие как:

Изменить порт по умолчанию (22)
Надежные пароли и парольная фраза
Отключить аутентификацию на основе хоста
Создать список разрешенных пользователей
Настроить время простоя
Принудительный протокол SSHv2
Отключить пустые пароли
Используйте fail2ban в качестве меры против грубой силы
Войти все
Настройте SSH-ключи и доверяйте только открытым ключам в .ssh / authorized_keys

5

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

— CVn

@ MichaelKjörling - Да, конечно, запутанный sudo может быть таким же вредным, как PermitRoot;)

См. Unix.stackexchange.com/a/2944/9454

— Восстановить Монику - М. Шредер

1

Изменение порта на самом деле вредно во многих сценариях само по себе. И это не более чем безопасность от неясности.

— 0xC0000022L

+1 за упоминание fail2ban, поскольку атаки методом "грубой силы" - это не только проблема SSH, но и всего остального на машине. Вам не нужно никуда получать права root или системы, чтобы «захватить» машину для практических целей (доступ к личным данным, использование в качестве дампа файлов, использование для фишинга и т. Д.).

— Эрик Грандж

8

Вы правы в том, что имя пользователя root и пароль символа X + Y криптографически по крайней мере так же надежны, как имя пользователя X и пароль символа Y. На самом деле это еще более безопасно, потому что имена людей легко угадать (боты могут просто попробовать john, mike, bill и т. Д. И т. Д., И это то, что многие из них делают вместо того, чтобы пробовать root). И вам особенно не повезло, если это целенаправленная атака, потому что, если кто-то хочет взломать сервер компании, не составит труда узнать имя (ник) сисадмина.

И как только злоумышленник получает доступ к учетной записи, которую системный администратор использует для входа в систему по протоколу ssh (а затем использует suили sudoдля выполнения своих задач), он может заразить сеанс этого пользователя программой, которая отправит пароль root атакующего, когда системный администратор введет следующую команду. время.

Это любой тип корневых учетных записей, которые (или должны) считаться плохими с точки зрения безопасности. «Обычный» логин пользователя -> цепочка su / sudo добавляет контрольный журнал. На простом английском языке: это позволяет узнать, кто что сделал.

Особый случай может быть тот, где только один человек имеет root-доступ. В этом случае использование дополнительного «обычного» пользователя не принесет особой пользы (по крайней мере, я никогда не смогу увидеть это значение). Но в любом случае - вы все равно должны иметь простого пользователя в системе (для неадминистративных задач, запуска wget и т. Д .;)).

— skarap
источник

4

Что такого опасного в том, чтобы включить root-вход (особенно при отключенном парольном входе)

Злоумышленнику (бот / ботнет / хакер) нужно только угадать пароль и получить полный контроль над вашей системой, если вы открыты для Интернета. Кроме того, ни одна из системных учетных записей (www-data, proxy и т. Д.) Не должна иметь возможность входить в систему по SSH по тем же причинам.

Если вы отключили вход по паролю (например, с использованием открытого ключа), учтите, что тот, кто получит закрытый ключ, получит полный контроль над вашей системой. Узнайте, почему использование открытого ключа с пользователем лучше ниже.

И в чем разница между именем пользователя X и паролем Y или корневым именем пользователя и паролем X + Y с точки зрения безопасности в случае, если разрешена аутентификация по паролю?

Дополнительное имя пользователя может добавить уровень безопасности, поскольку: а) злоумышленник должен знать и пару, имя пользователя и пароль; б) в случае, если злоумышленник проникнет в вашу систему, он не получит немедленного доступа к привилегированной учетной записи, добавив немного нюансов для злоумышленника.

В этом случае открытый ключ также является плюсом, поскольку:

Злоумышленнику нужен твой открытый ключ
Злоумышленнику нужен пароль (или метод аутентификации), чтобы получить повышенные привилегии

— Braiam
источник

1

Очень немногие пароли, которые я использую, содержат менее 20 случайных буквенно-цифровых символов (установите [A-Za-z0-9] плюс несколько специальных символов). 20 таких символов (т.е. длина 20 из набора символов 40) дает вам порядка 10 ^ 32 комбинаций. 128 битов энтропии порядка 10 ^ 38. Несмотря ни на что, разница невелика, и SSH-сервер может свободно реализовывать любые ограничения скорости, которые ему нравятся, так что в этом случае вы не будете атаковать грубой силой в автономном режиме. Там нет ничего плохого в паролях, если вы можете жить с ними так же трудно запомнить, как 128-битный ключ.

— CVn

@ michael shh ... не указывайте диапазон, теперь хакеры знают, что им следует использовать радужные таблицы порядка 20 символов длиной ...?

— Брайам

6

Таблицы @Braiam Rainbow полезны только в том случае, если злоумышленник имеет доступ к хэшам для поиска в автономном режиме. В данном случае у злоумышленника есть только ответ сервера для проверки, который, вероятно, ограничен только таким количеством попыток - и намного медленнее.

— Питер

@ Петер взлетел, я испортил и словарь, и хэши, но в любом случае ОП спросил, почему он не должен использовать слабые или пустые пароли, ведь это смешно, поэтому я пришел с нелепыми ситуациями, почему он не должен. Извините, что меня не интерпретировали таким образом, и меня приняли за FUD.

— Брайам

2

Если вам хочется попробовать несколько паролей 1,8 * 10 ^ 35 (и это только для диапазона 18-22 случайных символов из набора из 40, и вы не знаете, какие символы вне набора [A-Za-z0- 9] Я использую), я почти сказал, повеселиться. Это примерно 117,1 бит энтропийного эквивалента (2 ^ 117,1 ~ 1,78 * 10 ^ 35), и, как указал @Peter, вам, скорее всего, потребуется провести онлайн- атаку. Хранение всех этих паролей (без сжатия) требует примерно 3,6 * 10 ^ 36 байт или 3 * 10 ^ 24 ТиБ (и если эта цифра неверна на несколько порядков, кого это волнует? ). Ключевое слово случайное .

— CVn

1

Это не совсем плохо, если вы принимаете меры предосторожности. Например, вы можете установить CSF (Configure Server Firewall) и указать количество разрешенных попыток сбоя, поэтому, если кто-то попытался, скажем, более 5 попыток сбоя?, Они автоматически блокируются. Так что вся первая часть лучшего ответа не будет проблемой вообще. Это случалось со мной много раз, и, к счастью, все участники были заблокированы навсегда. Я думаю, для сервера это не большая проблема, если вы единственный человек, который управляет сервером, но, конечно, если есть много системных администраторов, или если вы работаете в организации, то, очевидно, не используйте корень. Также для настольного ПК, я полагаю, лучше использовать другую учетную запись, поскольку существует угроза безопасности, поскольку вы используете много программного обеспечения, но на сервере вы не Если вы выбираете случайное программное обеспечение, которому вы не доверяете, вы должны поддерживать его как можно ниже. Итак, вывод таков: нет, это не очень вредно, если вы знаете, как правильно управлять сервером.

— Дон Диланга
источник