Какова цель файла /etc /shadow в операционной системе Linux? Кроме того, это то же самое для клиентов SUSE? Существует один файл теневого кэша, какова цель этого?
8
4 ответа
16
С самого начала операционные системы Unix и Unix-стиля (включая Linux) всегда сохраняли пароли в виде криптографических хэшей (1). Эти хэши изначально хранились в /etc/passwd , но этот файл должен был быть читаемым для всего мира, чтобы сделать информацию доступной для других целей - даже простой ls -l должен прочитать /etc/passwd , чтобы преобразовать числовое значение каждого владельца файла идентификатор пользователя для их имени пользователя для отображения. Однако наличие хешированных паролей в общедоступном файле позволило злоумышленникам легко получить эти хэши и попытаться сгенерировать используемые пароли (2) для учетных записей других пользователей.
Чтобы предотвратить это, хешированные пароли в конечном итоге были перемещены в файл, доступный для чтения только пользователю root (и иногда привилегированной группе администраторов), /etc/shadow . Это скрывает хэши от обычных пользователей системы, оставляя их доступными для аутентификации пользователей.
Примечания:
Педантичный, я знаю, но сохраненные пароли не зашифрованы. Они хэшируются с использованием криптографически безопасного (по крайней мере, на момент написания) алгоритма хэширования. Основные отличительные особенности здесь заключаются в том, что хэши имеют фиксированную длину (длина зашифрованного текста зависит от длины зашифрованного текста) и необратимы (зашифрованный текст может быть расшифрован; хешированный текст не может).
Поскольку хэши имеют фиксированную длину, существует бесконечное количество входных данных, которые будут соответствовать любому заданному хеш-представлению. Поэтому злоумышленник может найти рабочий пароль, который не обязательно совпадает с паролем пользователя-владельца - хотя это очень маловероятно, учитывая размер современных криптографических хэшей.
6
Файл /etc/shadow был создан из соображений безопасности и содержит зашифрованный пароль каждого пользователя.
Первоначально зашифрованный пароль хранился в /etc/passwd . /etc/passwd должен был быть читаемым во всем мире, чтобы система могла сопоставлять идентификаторы пользователей с именами пользователей, и чтобы пользователи могли находить информацию друг о друге, например домашний каталог другого пользователя, или свой номер телефона, который традиционно хранился в поле "gecos" и отображается утилитой "finger".
Но потом люди поняли, что это проблема безопасности. Любой, у кого достаточно времени, может сделать так называемую атаку грубой силой, программно генерируя зашифрованные пароли для каждого возможного пароля. Если злоумышленник сделал это, фактически не пытаясь войти в систему через telnet или ssh , система не могла бы знать, что он подвергался атаке.
Таким образом, зашифрованный пароль был перемещен во вновь созданный /etc/shadow , который доступен для чтения только пользователю root.
Он также содержит другую информацию, которую файл /etc/passwd не поддерживает, связанную с учетной записью пользователя и паролем, например, когда пароль был изменен в последний раз и когда он истекает.
Смотрите man 5 shadow (веб-версия) для полной информации о формате файла.
Я не могу сказать, так ли это для SUSE, не зная, с какой версией SUSE вы имеете дело. Например, ваша система SUSE может использовать Blowfish вместо MD5.
Вы также подразумевали, что смешивали свой файл /etc/shadow с системой, работающей под другим дистрибутивом Linux, но не сказали, что это за другой дистрибутив.
См., Например, Проблемы миграции теневого файла с SuSE 9.3 на Ubuntu Server x86_64 .
Чтобы попытаться выяснить это, откройте /etc/shadow и посмотрите, начинается ли поле зашифрованного пароля с $1$ или $2$ . Если он содержит $1$ , то он MD5 и совместим с большинством других дистрибутивов. Если он содержит $2$ , то это, вероятно, Blowfish в соответствии с теневыми файлами Blowfish в Debian .
Если вы используете Ubuntu, первый результат поиска в Google для Ubuntu Blowfish может быть хорошей отправной точкой.
3
Пользователи перечислены в /etc/passwd . Этот файл содержит много информации, используемой системой, не только для того, чтобы пользователи могли войти в систему.
Каждая строка соответствует записи пользователя, а различные поля разделены двоеточиями. Первым полем является логин, за которым следует соответствующий пароль.
Зашифрованные пароли раньше хранились в этом поле. Тем не менее, файл /etc/passwd должен быть доступен для чтения всем в системе, поэтому шифрование не предотвращает атаки методом "грубой силы", как было сказано @Mikel. Решение состояло в том, чтобы переместить эти зашифрованные пароли в файл, доступный только для пользователя root: /etc/shadow .
Таким образом, /etc/shadow содержит зашифрованные пароли пользователей системы. Система знает, что она должна проверять пароли в этом файле, когда поля паролей в /etc/passwd содержат только один символ x (что означает « перейти к /etc /shadow»)
0
Давайте посмотрим, смогу ли я получить все положительные голоса в мире, так как я написал то, что стало Linux Shadow Password Suite в 87 году;)
Исходный файл /etc/passwd содержал модифицированный хэш-пароль открытого текста на основе DES. В то время, когда была создана функция crypt() , считалось (и это было заявлено создателями операционной системы UNIX), что атаки на хэш паролей были бы невозможны из-за количества возможных паролей и использования 12-битный (4,096 возможных значений) "соль". Каждый возможный пароль в виде открытого текста имел 4096 возможных значений хэширования и 64-битный результат хеширования, что давало в общей сложности 2 ^ 72 возможных хэшей пароля.
Как упоминалось в другом постере, /etc/passwd также использовался различными утилитами для сопоставления имен пользователей и значений UID (файл /etc/group предоставляет аналогичную функцию для групп), и для этого требовалось, чтобы он был читаем для всего мира.
В 1980-х годах стало очевидным, что словарные атаки против хэша пароля, хранящегося в /etc/passwd становятся выполнимыми, и /etc/shadow была введена в AT & T UNIX в раннем выпуске System V. Я задокументировал, какие руководства я использовал для написания оригинальная библиотека Shadow, и с тех пор я забыл, но это был определенно ранний выпуск System V, вероятно SVR3.2.
То, что сделал AT & T, и то, что я реализовал для SCO Xenix (первоначальный SCO Xenix, а не позднее злой SCO Xenix) в 87 году, который в конечном итоге вошел в использование в Linux, - это просто перенес хешированный пароль в /etc/shadow . Это предотвратило атаку «Drive-by», когда непривилегированный пользователь получил копию /etc/passwd и провел атаку против нее. Если вы знакомы с тем, почему я в первую очередь написал Shadow, у меня был пользователь, который загружал мой файл /etc/passwd через UUCP в те времена, когда мы все еще использовали UUCP практически для всего.
К тому времени, когда Linux был создан и получил широкое распространение, было очень много инструментов для атаки на хэши паролей. Высокопроизводительные повторные реализации crypt() были одной из возможностей, а атаки на основе словаря с помощью таких инструментов, как Crack и libcrack, были другими. Первоначальный порт был сделан Нейтом Холлоуэем и Флорией Ля Рош (я дал им должное, я не знаю, делал ли кто-нибудь работу до них).
В конце концов использование хэшей на основе crypt() даже в защищенном файле перестало быть безопасным, и были сделаны первоначальные изменения хеша на основе MD5 . В итоге MD5 считался слишком слабым, и использовались более новые хэши.
Теоретически достаточно сильный хеш может храниться в /etc/passwd . Плохая эксплуатационная безопасность означает, что многие системы имеют свои файлы /etc/shadow доступные через различные векторы атаки - "Я украл файлы резервных копий", вероятно, является самым простым.