Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материалаРеферат

Содержание


Файл /etc/passwd
Подробнее о /etc/passwd
ССЫЛКА 06 использовании паролей в системе безопасности рассказывается в главе 2.
Файл /etc/shadow
Подробнее о /etc/shadow
Декабрь (31) 11292 11657 12022 12387 12753 13118
Последнее замечание
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   101

Файл /etc/passwd


Желающий войти в систему должен ввести имя пользователя и пароль, которые проверяются по базе данных пользователей, хранящейся в файле /etc/passwd. В нем, кроме всего прочего, хранятся пароли всех пользователей (при использовании теневых паролей из него можно узнать, в каком другом файле они хранятся). При подключении к системе введенный пароль сверяется с паролем, соответствующим данному имени, и в случае совпадения пользователь допускается в систему, после чего запускается программа, указанная для данного имени пользователя в файле паролей. Если это командная оболочка, пользователь получает возможность вводить команды.

Чтобы понять, как это работает, давайте посмотрим на файл passwd. Находится он в каталоге /etc и может быть прочитан кем угодно. Последнее необходимо, чтобы могли работать программы, проверяющие имена и идентификаторы пользователей. Когда-то в этом файле хранились пароли пользователей, отсюда его имя. Взгляните на листинг 1.1. Это файл passwd в старом стиле. Давайте пройдемся по всем его полям и выясним их назначение.

Листинг 1.1. Файл /etc/passwd в старом стиле

root::1i DYwrOmhmEBU: 0:0: root:: /root: /bin/bash

bin:*:1:1:bin:/bin:

daemon:*:2:2:daemon:/sbin:

adm:*:3:4:adm:/var/adm:

lp:*:4:7:lp:/var/spool/lpd:

sync:*:5:0:sync:/sbin:/bin/sync

shutdown:*:6:11:shutdown:/sbin:/sbin/shutdown

halt:*:7:0:halt:/sbin:/sbin/halt

mail:*:8:12:mail:/var/spool/mail:

news:*:9:13:news:/var/spool/news:

uucp:*:10:14:uucp:/var/spool/uucp:

operator:*:11:0:operator:/root:

games:*:12:100:games:/usr/games:

gopher:*:13:30:gopher:/usr/1ib/gopher-data:

ftp:*:14:50:FTP User:/home/ftp:

man:*:15:15:Manuals Owner:/:

majordom:*:16:16:Majordomo:/:/bin/false

postgres:*:17:17:Postgres User:/home/postgres:/bin/bash

mysql:*:18:18:MySQL User:/usr/local/var:/bin/false

silvia:1iDYwrOmhmEBU:501:501:Silvia Bandel:/home/silvia:/bin/bash

nobody:*:65534:65534:Nobody:/:/bi n/false

david:1iDYwrOmhmEBU:500:500:David A. Bandel :/home/david:/bin/bash

Файл паролей имеет жестко заданную структуру. Можно заметить, что содержимое файла представляет собой таблицу. Каждая строка файла — это запись таблицы. Каждая запись состоит из нескольких полей. Поля файла passwd, как принято и в некоторых других служебных таблицах в Unix, разделяются двоеточием, поэтому двоеточия нельзя использовать ни в одном из полей. Всего имеется семь полей: имя пользователя, пароль, идентификатор пользователя, идентификатор группы, поле GECOS (оно же поле комментариев), домашний каталог и командная оболочка входа в систему.

Подробнее о /etc/passwd

В первом поле указывается имя пользователя. Оно должно быть уникальным — нельзя, чтобы два пользователя системы имели одно и то же имя. Если вы попробуете добавить в файл двух пользователей с одинаковыми именами (для этого вам придется вручную отредактировать файл, так как программы useradd, coastool и LISA не позволят вам сделать этого), то любая программа, начав поиск по имени пользователя, закончит его на первом из этих двух имен и никогда не доберется до второго. А значит, второй пользователь просто не сможет войти в систему, поскольку при входе всегда будет проверяться пароль и назначаться UID первого пользователя. Стало быть, второй пользователь как бы и не существует. Поле имени является единственным полем, значение которого должно быть уникальным. Во втором поле хранится пароль пользователя. Для того чтобы обеспечить защиту системы, пароль хранится в хэшированном виде. Термин «хэширован-ный» в данном контексте означает «зашифрованный». В случае с Linux пароль шифруется по алгоритму DES (Data Encryption Standard). Длина хэшированно-го пароля в этом поле всегда равна 13 символам, причем некоторые из символов, такие как двоеточие и одинарная кавычка, никогда не встречаются среди них (см. раздел «Файл /etc/shadow»). Любое другое значение поля, отличное от правильного хэшированного 13-символьного пароля, делает невозможным вход данного пользователя в систему, за одним чрезвычайно важным исключением: поле пароля может быть пустым. Например, одна из записей файла /etc/passwd может выглядеть следующим образом:

david::500:500:David A. Bandel:/home/david:/bin/bash

Во втором поле не стоит ничего, даже пробела, это означает, что соответствующему пользователю не нужен пароль для входа в систему. Другими словами, данный пользователь может войти в систему, не указывая вообще никакого пароля. Скорее всего, это не то, что вам нужно. Поэтому файл /etc/passwd всегда следует проверять на наличие записей с пустыми паролями. Если изменить пароль, хранящийся в поле, добавив к нему какой-либо символ, например одинарную кавычку, то данная учетная запись окажется заблокированной, а соответствующий пользователь более не сможет войти в систему. Дело в том, что после добавления в 14-символьный хэшированный пароль нелегального символа система отказывалась аутентифицировать пользователя с таким паролем. Это достаточно старый прием, и в настоящее время его практически не используют. Современные системы для подключения пользователей к системе используют механизм /etc/shadow (о нем чуть позже), который предусматривает более правильные способы блокирования учетной записи без изменения пароля. Однако во времена, когда механизм теневых паролей еще не был разработан, системные администраторы, в чьем ведении находились системы с большим числом пользователей (а когда пользователей много, всегда найдутся те, кто не прочь попытаться взломать чего-нибудь на досуге), зачастую сами блокировали пароль пользователя root, помещая одинарную кавычку перед первым его символом. Вместо заблокированной таким образом учетной записи заводилась другая учетная запись с привилегиями суперпользователя, которой, как правило, назначали имя toor или tuber.

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


ПРИМЕЧАНИЕ

Атака по словарю (dictionary attack) относится к методам взлома паролей грубой силой и подразумевает использование словаря и известной затравки. Атака состоит в переборе всех слов словаря, шифрования их с данной затравкой и сравнении результата со взламываемым паролем. При этом кроме слов из словаря обычно рассматриваются и некоторые их модификации, например, все буквы заглавные, только первая буква заглавная и добавление чисел (обычно только 0-9) в конец всех этих комбинаций. Подобным образом можно взломать достаточно много легко угадываемых паролей.

Из листинга 1.1 видно, что у пользователей root, silvia и david один и тот же хэ-шированный пароль. Это сделано мною преднамеренно, на практике такого не происходит. Признаюсь сразу же: так выглядит хэшированный пароль «silvia». Подобная очевидность пароля (особенно для пользователя silvia) ничем не лучше отсутствия пароля как такового. Столь простой пароль находится любой приличной программой взлома примерно за 3 наносекунды, однако я уже сообщил вам его, так что можете считать, что я сэкономил вам время.


ССЫЛКА

06 использовании паролей в системе безопасности рассказывается в главе 2.

В третьем поле указывается идентификатор пользователя. Об идентификаторах уже говорилось ранее, поэтому не буду повторяться. Идентификатор пользователя не обязан быть уникальным, как думают некоторые. В частности, кроме пользователя root, может быть сколь угодно других пользователей с нулевым идентификатором, и все они будут обладать привилегиями суперпользователя. Таким образом, в примере, что я приводил три абзаца тому назад, добавление нового пользователя для целей администрирования делалось именно путем присвоения ему (пользователю toor, или tuber, или какому-нибудь другому) нулевого идентификатора.

Однако данный подход не свободен от определенных проблем. Предположим, вы так и сделали: создали нового пользователя с нулевым идентификатором и заблокировали пользователя root недопустимым символом в хэшированном пароле. После чего вошли в систему уже не как root, а как новый пользователь. А войдя и поработав некоторое время, решили отлучиться на несколько минут и, не желая выходить из системы, не подумали и заблокировали терминал. Досадно, конечно, но разблокировать терминал по возращении вам не удастся. Причина в том, что программе блокировки терминала важен лишь UID пользователя, заблокировавшего терминал, который в данном случае равен нулю. При поиске пользователя с нулевым идентификатором первым будет найден заблокированный пользователь root. Однако ничего не знающая об этом программа блокировки не станет смотреть далее и запросит пароль пользователя root Тупик. Итак, у данного подхода есть свои тонкости, не забывайте про них. Во второй части этой книги, когда речь пойдет о безопасности NFS, мы еще вернемся к вопросу взаимосвязей между идентификаторами и именем пользователя.

Четвертое поле содержит идентификатор группы (Group ID, GID). Группа, указанная в этом поле, называется первичной группой пользователя (primary group). Пользователь может принадлежать к нескольким группам, но одна из них обязательно должна быть первичной группой. Более подробно о группах будет рассказано в этой и в следующих двух главах.

Пятое поле теперь называют полем комментариев, но первоначальное его название — GECOS, от «GE Consolidated Operating System». При запросе информации о пользователе через finger или иную программу содержимое данного поля теперь возвращается как истинное имя пользователя. Поле комментариев может быть пустым.

Шестое поле задает домашний каталог пользователя. У каждого пользователя должен быть свой домашний каталог. Обычно пользователь, войдя в систему, оказывается в своем домашнем каталоге, но если такового не существует, то он попадает в корневой каталог. Назначая домашний каталог для некоторых учетных записей, следует быть внимательным. Например, домашним каталогом пользователя ftp следует сделать корневой каталог дерева каталогов, доступных через анонимный ftp, а не просто корневой каталог.

Седьмое и последнее поле задает командную оболочку входа в систему. Не всякую оболочку можно указать в этом поле. В зависимости от настроек системы в нем может быть указана только оболочка из списка допустимых оболочек. В OpenLinux список допустимых оболочек находится по умолчанию в файле /etc/shells (см. обсуждение РАМ далее в этой главе).

Как упоминалось ранее, время, когда пароли пользователей хранились в файле /etc/passwd, безвозвратно ушло в прошлое. Даже несколько лет назад вычислительных мощностей компьютера хватало на то, чтобы, сравнив хэшированный словарь с копией файла passwd, взломать приличное количество паролей, включая суперпользователя, всего за несколько дней, а то и часов. Теперь подобная процедура занимает всего несколько минут. Поэтому возникла потребность в ограничении доступа к хэшированным паролям. Появился механизм теневых паролей.

Файл /etc/shadow

Владельцем файла /etc/shadow является пользователь root и только он имеет право читать этот файл. Для его создания нужно взять имена пользователей и хэши-рованные пароли из файла passwd и поместить их в файл shadow, заменив при этом все хэшированные пароли в файле passwd символами х. Если вы посмотрите на файл passwd вашей системы, то увидите, что на месте хэшированных паролей там стоят символы х. Данный символ указывает системе на то, что пароль следует смотреть не здесь, а в файле /etc/shadow. Переход от простых паролей к теневым и обратно осуществляется посредством трех утилит. Для перехода к теневым паролям сначала запустите утилиту pwck. Она проверяет файл passwd на предмет всяких аномалий, из-за которых следующий шаг может закончиться неудачей или попросту зациклиться. После того как отработает pwck, запустите утилиту pwconv для создания /etc/shadow. Обычно это делается после ручного обновления файла /etc/passwd. Для возвращения к обычным паролям запустите pwuncov.

Файл теневых паролей во многих отношениях схож с файлом обычных паролей. В частности, первые два поля этих файлов одинаковы. Но помимо этих полей в нем, естественно, есть и дополнительные поля, отсутствующие в файле обычных паролей. Листинг 1.2. показывает содержимое типичного файла /etc/shadow.

Листинг 1.2. Файл /etc/shadow

root:1iDYwrOmhmEBU:10792:0:: 7:7::

bin:*:10547:0::7:7::

daemon:*:10547:0::7:7::

adm:*:10547:0::7:7::

lp:*:10547:0::7:7::

sync:*:10547:0::7:7::

shutdown:U:10811:0:-1:7:7:-1:134531940

halt:*:10547:0::7:7::

mail:*:10547:0::7:7::

news:*:10547:0::7:7::

uucp:*:10547:0::7:7::

operator:*:10547:0::7:7::

games:*: 10547:0: :7:7::

gopher:*:10547:0::7:7::

ftp:*:10547:0::7:7::

man:*:10547:0::7:7::

majordom:*:10547:0::7:7::

postgres:*:10547:0::7:7::

mysql:*:10547:0::7:7::

si1via:1iDYwrOmhmEBU:10792:0:30:7:-l::

nobody:*:10547:0::7:7::

david:1iDYwrOmhmEBU:10792:0::7:7::

Подробнее о /etc/shadow

Назначение первого поля файла shadow такое же, как и у первого поля файла passwd.

Второе поле содержит хэшированный пароль. Реализация теневых паролей в OpenLinux допускает хэшированные пароли длиной от 13 до 24 символов, однако программа шифрования паролей crypt умеет выдавать только 13-символь-ные хэшированные пароли. Символы, используемые в хэше, берутся из набора, состоящего из 52 букв алфавита (строчных и прописных), цифр 0-9, точки и наклонной черты вправо (/). Итого выходит 64 символа, допустимых в поле хэши-рованного пароля.

Затравка, таким образом, которая, как и ранее, представляет собой первые два символа, может выбираться из 4096 возможных комбинаций (64x64). Для шифрования используется алгоритм DES с 56-битным ключом, то есть пространство ключей этого алгоритма насчитывает 256 ключей, что приблизительно равно 72 057 590 000 000 000 или 72 квадрильонам. Само по себе число может выглядеть впечатляющее, однако перебрать все ключи из пространства такого размера можно на самом деле за весьма короткое время. Относительно недавно совместными усилиями компьютеров, разбросанных по всему миру, подобный 56-битный код был взломан менее чем за два часа. (Время от времени в Интернете проводятся специальные акции по расшифровке сообщения, зашифрованного определенным алгоритмом, с целью проверки его криптостойкости, принять участие в которых может любой желающий, согласный выделить часть вычислительных мощностей своего компьютера для перебора определенной части пространства ключей.) Коль скоро речь зашла о переборе, замечу, что программы, реализующие атаку по cловарю, обычно перебирают лишь ту малую часть пространства ключей, которая используется людьми (то есть слова из словаря и их модификации), причем с потрясающей скоростью. Поэтому единственная вещь, делающая пароли действительно защищенными, это невозможность прочтения файла паролей никем, кроме суперпользователя.

С третьего поля начинается информация об устаревании пароля (см. раздел «Изменение информации об устаревании пароля» далее в этой главе). В нем хранится число дней, прошедших с 1 января 1970 года до дня последнего изменения пароля. В табл. 1.1. показаны числа, которые последовательно появятся в этом поле при изменении пароля первого числа каждого месяца в течение 2000-2005 годов.

Таблица 1.1. Значения, которые можно наблюдать в третьем поле файла shadow, если менять пароль первого числа каждого месяца

Месяц/Год 2000 2001 2002 2003 2004 2005

Январь (31) 10957 11323 11688 12053 12418 12784

Февраль (28/29) 10988 11354 11719 12084 12449 12815

Март (31) 11017 11382 11747 12112 12478 12843

Апрель (30) 11048 11413 11778 12143 12509 12874

Май(31) 11078 11443 11808 12173 12539 12904

Июнь(30) 11109 11474 11839 12204 12570 12935

Июль (31) 11139 11504 11869 12234 12600 12965

Август(31) 11170 11535 11900 12265 12631 12996

Сентябрь(30) 11201 11566 11931 12296 12622 13027

Октябрь (31) 11231 11596 11961 12326 12692 13057

Ноябрь(30) 11262 11627 11992 12357 12723 13088

Декабрь (31) 11292 11657 12022 12387 12753 13118

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

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

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

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

В предпоследнем поле хранится день блокировки учетной записи.

Последнее поле зарезервировано и не используется.


Последнее замечание

И еще одна вещь, прежде чем мы двинемся дальше. В файлах passwd и shadow вы можете встретить записи, подобные этой:

+:х:0:0:::

ИЛИ +:*:0:0::-1:-1::

Такие записи могут встречаться лишь в самом конце этих файлов, после всех обычных записей. Если вы не используете службу NIS (Network Information Services, ранее эта служба называлась «Yellow Pages», однако имя было изменено из-за конфликта с торговой маркой British Telecom), то их следует удалить. Тем, кому очень хочется или необходимо использовать NIS, следует знать, что NIS является чрезвычайно небезопасным протоколом со слаборазвитой системой авторизации. NIS+ несколько лучше своего предшественника, однако реализации сервера NIS+ для Linux (пока) нет. Работать с NIS означает подвергать свою систему большому риску, от которого лучше воздержаться. Мы больше не будем обсуждать здесь проблемы безопасности NIS, оставив их для отдельной книги.