Управление доступом Offline

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

Часто для принятия решений в особых обстоятельствах используются возможности POSIX или средства управления доступом на основе ролей (например, когда необходимо разрешить переустановку принтера или демона каждому, кто работает в конкретном отделе), в то время как при решении каждодневных задач ваша административная команда продолжает полагаться на утилиту sudo и учетную запись суперпользователя. В некоторых случаях (например, если это оговорено в контракте) для узлов необходимо использовать такие мощные и "ударопрочные" системы, как SELinux.

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

 

Пароль суперпользователя

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

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

Самой важной характеристикой хорошего пароля является его длина. Пароль пользователя root должен состоять как минимум из восьми символов, так как даже семи-символьные пароли взламываются достаточно легко. В системах, где применяются пароли DES (Data Encryption Standard — стандарт шифрования данных), задавать более Длинный пароль не имеет смысла, потому что обрабатываются только первые восемь символов. В начале рассказывается о том, как разрешить использование систем шифрования MD5 или Blowfish, которые позволяют паролям иметь большую длину.

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

Сегодня наиболее широкое распространение получил подход, заключающийся в выборе пароля по принципу "шокирующего абсурда". Этот принцип был определен Грейди Уордом (Grady Ward) в ранней версии списка часто задаваемых вопросов (FAQ), посвященного выбору идентификационной фразы по системе PGP (Pretty Good Privacy).

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

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

Если ваш узел включает сотни компьютеров, то нужно ли вам готовить сотни root-паролей? Это зависит от среды и толерантности к риску, но, скорее всего, нет. Практика показывает, что для компьютеров-клонов (например, настольных АРМ) вполне подойдет один и тот же root-пароль. При этом серверам следует подбирать уникальные пароли. Все важные части сети и инфраструктура, обеспечивающая маршрутизацию, должны быть защищены по отдельности.

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

Пароль суперпользователя следует менять в следующих случаях:

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

 

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

Данный список FAQ был написан для отдельных пользователей системы PGP. В контексте системного администрирования вам следует учесть потенциальные возможности для нападения. Как бы восприняли ваш вариант "шокирующего абсурда" присяжные, которым, не дай бог, придется рассматривать ваше дело о сексуальных домогательствах?

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

 

Регистрация под именем root

Поскольку суперпользователь является таким же членом системы, как и остальные пользователи, можно войти в систему непосредственно под именем root. Однако оказывается, что это довольно неудачное решение. Во-первых, не будет сделано никаких записей о том, какие операции выполнял суперпользователь. Согласитесь, не очень приятно обнаружить, что вчера ночью в 3:00 вы что-то поменяли, но никак не можете вспомнить, что именно. Еще хуже, если такой доступ был несанкционированным и необходимо выяснить, какой ущерб системе нанес нарушитель. Во-вторых, сценарий регистрации суперпользователя не предполагает сбора дополнительной идентифицирующей информации. Когда под именем root в систему могут входить несколько пользователей, не существует способа определить, кто именно и когда это делал.

Вследствие упомянутых причин в большинстве систем регистрация под именем root может быть запрещена на терминалах, в оконных системах и по сети, т.е. везде, кроме системной консоли.(Система Ubuntu Linux пошла еще дальше. По умолчанию система не содержит никакого действующего пароля для учетной записи root, и в ней необходимо использовать команду sudo.) Мы рекомендуем следовать этой схеме.

 

Команда su: замена идентификатора пользователя

Лучше получать доступ к учетной записи root с помощью команды su. Будучи вызванной без аргументов, она выдает приглашение на ввод пароля суперпользователя, а затем запускает интерпретатор команд с правами пользователя root. Интерпретатор будет выполняться в привилегированном режиме, пока не завершит работу (при нажатии комбинации клавиш <Ctrl+D> или по команде exit). Команда su не фиксирует действия, производимые в среде интерпретатора, но добавляет запись в журнальный файл с указанием, кто и когда вошел в систему под именем суперпользователя.

Команда su способна также подставлять вместо имени root имена других пользователей. Иногда единственный способ помочь пользователю в решении проблемы — войти с помощью команды su в его среду и разобраться в происходящем, так сказать, "на месте".

Зная чей-либо пароль, можно непосредственно зарегистрироваться в системе под его именем, введя команду su имя_пользователя. В ответ будет выдан запрос на ввод пароля. При использовании в качестве ключа команды su дефиса (-) интерпретатор перейдет в режим регистрации. Точная реализация этого режима зависит от конкретного интерпретатора команд, но обычно в этом режиме меняются количество и имена файлов запуска, считываемых интерпретатором. Например, в режиме регистрации интерпретатор bash считывает файл ~/ .bash_profile, а вне этого режима — файл ~/ .bashrc. При диагностике проблем конкретного пользователя режим регистрации позволяет максимально точно воспроизвести среду, в которой он работал.

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

Рекомендуем взять за правило при вводе команды указывать полное имя, например /bin/su или /usr/bin/su, а не просто su. Это послужит определенной защитой от тех программ с именем su, которые преднамеренно были прописаны в переменной среды path злоумышленником, намеревавшимся собрать хороший "урожай" паролей. (По аналогичной причине настоятельно рекомендуем не включать запись "." (текущий каталог) в переменную path интерпретатора команд. Несмотря на очевидное удобство, подобная конфигурация приводит к тому, что можно непреднамеренно запустить "специальную" версию какой-нибудь системной команды, которую злоумышленник оставил в качестве приманки. Пользователю root следует быть бдительным вдвойне.)

В некоторых системах, чтобы использовать команду su, необходимо быть членом группы wheel.

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

Утилита sudo: ограниченный вариант команды su

Без организации управления доступом на основе ролей (RBAC) или такой системы, как SELinux, трудно предоставить кому-то право выполнять конкретную административную операцию (например, создавать резервные копии), не предоставив возможность свободно работать в системе. Если же учетная запись root доступна группе администраторов, то вы и понятия не будете иметь о том, кто ею пользуется и что он при этом делает.

Чаще всего для получения прав суперпользователя применяется утилита sudo. Она работает во всех рассматриваемых нами системах, а ее исходный код можно получить на веб-сайте sudo.ws.

В системе Solaris предусмотрена команда pf exec, предоставляющая возможности, подобные возможностям программы sudo, которая реализована на базе собственной системы RBAC.

Утилита sudo в качестве аргумента принимает командную строку, которая подлежит выполнению от имени root-пользователя (или другого уполномоченного пользователя). Утилита обращается к файлу /etc/sudoers, где содержится список пользователей, имеющих разрешение на ее выполнение, и перечень команд, которые они могут вводить на конкретном компьютере. Если запрашиваемая команда разрешена, утилита sudo приглашает пользователя ввести его собственный пароль и выполняет команду от имени суперпользователя.

Далее утилита sudo позволяет, не вводя пароль, выполнять другие команды, но только до тех пор, пока не наступит пятиминутный период бездействия (его продолжительность можно менять). Такая мера служит защитой от тех привилегированных пользователей, которые оставляют свои терминалы без присмотра.

Утилита sudo ведет журнал, где регистрируются выполненные команды, компьютеры, на которых они выполнялись, и вызвавшие их пользователи, а также каталоги, из которых запускались команды, и время их вызова. Эта информация может направляться в системный журнальный файл syslog или сохраняться в любом другом файле по усмотрению пользователя. Мы рекомендуем направлять ее на защищенный центральный компьютер. Строка журнального файла, содержащая данные о пользователе randy, который выполнил команду sudo  /bin/cat etc/sudoers, может выглядеть следующим образом.

Dec 7 10:57:19 tigger sudo: randy: TTY=ttypO; PWD=/tigger/users/randy; USER=root; COMMAND=/bin/cat /etc/sudoers

Существует единая версия файла /etc/sudoers, которая используется на всех компьютерах. Сам файл выглядит примерно так.

Define aliases for machines in CS & Physics departmentsHost_Alias CS = tigger, anchor, piper, moet, sigiHost_Alias PHYSICS = eprince, pprince, icarus

Define collections of commandsCmnd_Alias DUMP = /sbin/dump, /sbin/restoreCmnd_Alias PRINTING = /usr/sbin/lpc, /usr/bin/lprm

Cmnd_Alias SHELLS = /bin/sh, /bin/tcsh, /bin/bash, /bin/ksh, /bin/bsh

Permissions

mark, ed PHYSICS = ALL

herb CS = /usr/sbin/tcpdump: PHYSICS = (operator) DUMP

lynda ALL = (ALL) ALL, !SHELLS

%wheel ALL,! PHYSICS = NOPASSWD: PRINTING

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

В каждую спецификацию прав доступа включается информация о следующем:

  • пользователях, к которым относится запись;
  • компьютерах, на которых пользователям разрешено выполнять соответствующие действия;
  • командах, которые могут выполняться указанными пользователями;
  • пользователях, от имени которых могут выполняться команды.

Первая строка спецификаций применяется к пользователям mark и ed, которые регистрируются в системе на компьютерах группы PHYSICS (eprince, pprince и icarus). Встроенный псевдоним ALL разрешает им вводить любые команды. Поскольку дополнительный список пользователей в скобках не указан, утилита sudo будет выполнять команды только от имени суперпользователя.

Пользователь herb может запускать утилиту tcpdump на компьютерах группы CS, а также выполнять команды резервного копирования на компьютерах группы PHYSICS. Обратите внимание, однако, что вторая группа команд получит привилегии не пользователя root, а пользователя operator. Реальная команда, которую пришлось бы ввести пользователю herb, выглядит примерно так.

ubuntu$   sudo -u operator /usr/sbin/dump Ou /dev/sdal

Пользователь lynda имеет право выполнять команды от имени любого пользователя на любом компьютере, но он не может запускать большинство распространенных интерпретаторов команд. Означает ли это, что он не может получить доступ к интерпретатору? Конечно, нет.

aix$   ср -р /bin/sh /tap/ah aix$    sudo /txnp/sh

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

В последней строке пользователям группы wheel разрешается выполнять команды печати 1рс и lprm от имени суперпользователя на всех компьютерах, за исключением eprince, pprince и icarus. Более того, от пользователей не требуется вводить пароль.

Обратите внимание на то, что команды в файле /etc/sudoers приводятся с указанием полного имени, чтобы пользователи не могли выполнять свои собственные программы и сценарии от имени суперпользователя. Разрешается также указывать допустимые аргументы команд (в приведенных выше примерах это не показано). В целом возможности файла sudoers очень велики, а рассмотренная конфигурация иллюстрирует лишь основные из них.

В системах ALX полезно включать в раздел Defaults файла sudoers следующую строку.

Defaults env_keep = "ODMDIR"

Наличие этой строки не позволит утилите sudo удалить переменную среды ODMDIR, которая указывает многим административным командам на специальную базу объектов ODM (Object Data Manager), в которой хранится значительная часть параметров ОС AIX, например список поддерживаемых и сконфигурированных устройств, информация о драйверах и пр.

Для модификации файла /etc/sudoers предназначена специальная команда visudo, которая проверяет, не редактируется ли файл кем-то посторонним, затем открывает его в редакторе, а перед инсталляцией файла выполняет синтаксический контроль. Последний этап особенно важен, поскольку ошибка в файле /etc/sudoers может не позволить повторно вызвать утилиту sudo для исправления файла.

Использование утилиты sudo имеет следующие преимущества.

  1. Благодаря регистрации команд значительно повышается степень административного контроля над системой
  2. Операторы могут выполнять специальные задачи, не имея неограниченных привилегий
  3. Настоящий пароль суперпользователя могут знать всего один-два человека
  4. Вызывать утилиту sudo быстрее, чем выполнять команду su или входить в систему под именем root
  5. Пользователя можно лишить привилегий, не меняя пароль суперпользователя
  6. Ведется список всех пользователей с правами пользователя root
  7. Меньше вероятность того, что интерпретатор команд, запущенный суперпользователем, будет оставлен без присмотра
  8. Управлять доступом ко всей сети можно с помощью одного файла

Утилита sudo имеет и недостатки. Самый большой из них заключается в том, что любая брешь в системе защиты того или иного привилегированного пользователя эквивалентна нарушению безопасности самой учетной записи root. Противостоять этому нелегко. Можно лишь предупредить тех, кто имеет право выполнять утилиту sudo, о необходимости максимально защищать свои учетные записи. Можно также регулярно запускать какой-нибудь программный взломщик паролей, проверяя "стойкость" паролей привилегированных пользователей.

Другой недостаток — возможность обмануть утилиту sudo с помощью таких уловок, как временный выход в интерпретатор команд из разрешенной программы либо выполнение команд sudo  sh или sudo  su, если они допустимы.

Во многих версиях систем UNIX утилита sudo (как способ разделения привилегий суперпользователя) является лучшим инструментом для встроенных систем управления доступом на основе ролей (RBAC). И вот почему.

  • Вы можете точно определить, как именно будут разделены привилегии суперпользователя. Ваш вариант может отличаться в ту или иную сторону от предлагаемого встроенной системой RBAC.
  • Простота конфигурации — общепризнанный факт (в основном, это касается установки, обслуживания и понимания происходящего).
  • Псевдонимы утилиты sudo для групп компьютеров, пользователей и команд функ ционально подобны ролям в системе RBAC.
  • Утилита sudo выполняется во всех системах UNIX и Linux. Вам не нужно беспокоиться об использовании различных систем RBAC на разных платформах.
  • Вы можете совместно использовать единственный на весь узел файл конфигурации.
  • Вы получаете бесплатную возможность высококачественного процесса регистрации в системе.

Основной недостаток sudo-ориентированного управления доступом состоит в том, что система остается уязвимой в случае, если будет нарушена защита учетной записи суперпользователя.

 

Хранилища паролей и их депонирование

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

Хранилище паролей может быть реализовано в виде некоторого программного (или программно-аппаратного) комплекса, который сохраняет пароли для конкретной организации более безопасным способом, чем тот, что предлагает Windows (например, с помощью флажка "Запомнить ваш пароль?"). Некоторые разработки сделали хранилище паролей почти необходимостью.

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

 

Системы управления паролями возникли после того, как в Сенате США был зарегистрирован законопроект "Акт о кибербезопасности 2009" (Cybersecurity Act of 2009), который предлагает значительно расширить полномочия федеральных властей в сфере безопасности компьютерных сетей. Этот законопроект (в случае его принятия) может существенно повлиять на структуру и саму суть современного Интернета, поскольку авторы законопроекта предлагают решать вопросы идентифицируемости и безопасности на государственном уровне с учетом особенностей различных производственных секторов. В некоторых случаях этот законопроект требует двухфакторной аутентификации, например пароль или парольная фраза плюс обмен сообщениями "вызов/ответ" (для проверки правильности реакции пользователя на непредсказуемый запрос системы). Хранилища паролей — это большое подспорье для компаний, которые должны безопасно и прозрачно управлять паролями не только собственных компьютеров, но и компьютеров своих клиентов.

В настоящее время доступно несколько программ для хранения паролей. Среди них программа KeePass — бесплатный, легкий и удобный в работе менеджер паролей с открытым исходным кодом, предназначенный для отдельных пользователей. Программа KeePass хранит пароли локально, предоставляет категорический (все или ничего) доступ к базе данных паролей, не выполняя при этом входа в систему. Продукты, предназначенные для крупных корпораций (например, от компании Cyber-Ark), могут стоить десятки тысяч долларов. Многие коммерческие предложения ориентированы либо на удовлетворение специальных требований пользователя, либо просто на количество запоминаемых паролей.

Мы используем собственную веб-ориентированную систему, которая имеет несколько ценных функций. Одна их них (наша любимая) называется "разбить стекло" (по аналогии с надписью на противопожарном оборудовании в отелях: "в случае крайней необходимости разбить стекло и дернуть за большую красную ручку").

В нашем случае "разбить стекло" означает получить пароль, к которому обычно нет доступа. В случае аварии вы можете взять на себя ответственность и запросить пароль. Система предоставит список системных администраторов и зарегистрирует все действия, совершаемые вами с помощью "аварийного" пароля. "Разрулив" ситуацию, вы должны изменить пароль и поместить в хранилище новый пароль.

"Низкотехнологичный" способ реализации депонирования паролей "позаимствован" у полиции, которая для хранения вещественных доказательств, собранных на месте преступления, использует специальные пронумерованные пакеты. Такие пакеты можно найти с помощью Интернета. До тех пор пока пакет не открыт, вы точно знаете, что никто не получил доступа к паролю, хранящемуся внутри него.

 

Комментарии (0)

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.