Общие сведения об управлении паролями общих учетных записей

Одним из действий, которое все чаще приходится выполнять администраторам, является регулярное изменение пароля для общих и привилегированных учетных записей, таких как встроенная учетная запись администратора или учетная запись пользователя root, учетная запись аварийного доступа, возможно, даже учетная запись процесса. Встроенную учетную запись администратора или пользователя root можно определить как учетную запись, существующую во всех версиях Windows®, Linux и UNIX, которая всегда имеет один идентификатор безопасности или пользователя. Учетные записи аварийного доступа создаются для упрощения осуществления аварийного доступа к защищенной системе. Эти учетные записи аварийного доступа или администратора иногда используются другими непривилегированными пользователями для получения доступа к ключевым системам в случае возникновения проблем. Наконец, учетные записи процессов – это учетные записи, используемые для выполнения служб, задач, приложений COM+ и внедренных элементов, таких как сценарии и другие двоичные файлы, для которых необходим вход в систему.

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

Администратор может быть вынужден сменить эти пароли в соответствие с используемыми рекомендациями или техническими требованиями, например, установленными законом Сарбейнса-Оксли (SOX), стандартом Payment Card Industry (PCI) или актом HIPAA (акт по обеспечению переносимости и возможности учета в системах для страхования в области здравоохранения). Иногда действия администратора обусловлены увольнением из компании бывшего администратора или технического специалиста, знающего пароли, опасностью разглашения брешей в системе безопасности или утратой возможности работы с кредитными картами. Несмотря на эти факторы, все сводится к тому, что администратору приходится изменять эти пароли по простой причине обеспечения безопасности компании и данных, которые должна защищать компания.

Знакомство с задачей

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

1. Чем старее становятся пароли, тем менее они безопасны.
2. Как правило, более длинные пароли труднее взламывать.
3. Способ проверки подлинности компьютеров не меняется только потому, что они принадлежат к домену. В каждом домене заключена основа рабочей группы.

Утверждение «чем старее становятся пароли, тем менее они безопасны» вводит в заблуждение. Оно означает только то, что для взлома компьютера необходимо только время. На вопрос: «Сколько времени занимает взлом пароля?» я обычно отвечаю, что определенный ответ отсутствует, и даю советы, помогающие получить ответ для определенной системы:

• Как много людей знают пароль?
• Работают ли все эти люди по-прежнему в компании?
• Если кто-либо из людей, знающих пароль для учетной записи, больше не работает в компании, покинул ли он компанию в дружественной обстановке?
• Запретили ли вы возможность загрузки с дискеты, устройства чтения компакт-дисков или дисков DVD или из сети?
• Являются ли пользователи компьютеров также и локальными администраторами?
• Используется ли во всех ваших системах одинаковый пароль для привилегированных учетных записей?

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

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

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

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

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

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

Более длинные пароли имеют экспоненциально большее количество вариантов сочетаний символов, и поэтому для их взлома требуется больше времени. Поэтому важно учитывать, составляет ли длина паролей менее 7 символов, от 8 до 14 символов или более 15 символов. И, если длина паролей менее 15 символов и используется операционная система Windows, отключено ли хеширование LAN Manager (LM) в качестве части процесса настройки системы или в результате применения групповой политики?

Как длина пароля влияет на что-либо? В случае Windows ответ простой. Помимо журнала процессов хеширования корпорация Майкрософт реализует два типа хеш-кодов для паролей, хеш-коды LM и хеш-коды MD4. По умолчанию Майкрософт использует хеш-коды LM, а значения сохраняются для всех паролей длиной до 14 символов, если хранение этих хеш-кодов не отключено намеренно. Эти пароли разделены на два семизначных значения — первое значение для первых 7 символов, а второе значение для вторых 7 символов, как показано на рис. 1.

Рис. 1. Пример таблицы хеш-кодов

Имя учетной записи	Идентификатор RID	Хеш-код LM	Хеш-код NT	Пароль	Примечания
Администратор	500	aad3b435b51404ee: aad3b435b51404ee	31d6cfe0d16ae931: b73c59d7e0c089c0	Пустой пароль	Хеш-код LM идентичен хеш-коду LM 20-символьного пароля.
Администратор	500	0182bd0bd4444bf8: aad3b435b51404ee	328727b81ca05805: a68ef26acb252039	7-символьный пароль = 1234567	Первая часть, представляющая первые 7 символов, идентична 8-символьному паролю.
Администратор	500	0182bd0bd4444bf8: 36077a718ccdf409	0182bd0bd4444bf8: 36077a718ccdf409	8-символьный пароль = 12345678	Первая часть, представляющая первые 7 символов, идентична 8-символьному паролю, но вторая часть отличается.
Администратор	500	aad3b435b51404ee: aad3b435b51404ee	b79d07c2ecb3d565: 033ece663f5a0b2e	20-символьный пароль = 9876543210 9876543210	Хеш-код LM идентичен пустому паролю, поскольку хеш-код LM не может быть создан для паролей, длина которых превышает 14 символов.
Сергей	1221	e52cac67419a9a: 224a3b108f3fa6cb6d	8846f7eaee8fb117: ad06bdd830b7586c	Identical	Вам понятно, почему хеш-коды LM и NT в этих трех примерах идентичны? Это означает, что все пароли для всех этих учетных записей идентичны. Корпорация Майкрософт никогда не меняла алгоритм хеширования.
Понедельник	1385	e52cac67419a9a: 224a3b108f3fa6cb6d	8846f7eaee8fb117: ad06bdd830b7586c	Identical
SvcAcctX	1314	e52cac67419a9a: 224a3b108f3fa6cb6d	8846f7eaee8fb117: ad06bdd830b7586c	Identical

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

Однако важно отметить, что хеш-коды LM хорошо всем знакомы и очень просты для обхода. Их единственная цель в текущих решениях состоит в обеспечении обратной совместимости с системами нижнего уровня, такими как Windows NT® 4.0.

Сейчас вы должны использовать пароли (в действительности кодовые фразы) длиной не менее 15 символов или даже больше, поскольку для них по определению не создается хеш-кодов LM. Если обязательное использование 15-символьных паролей невозможно в вашей среде, необходимо отключить хранение хеш-кодов LM как в процессе создания образа (с помощью локальной политики), так и в групповой политике Active Directory®.

Эта политика доступна в разделе «Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности». Просто установите для политики «Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля» значение «Включено».

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

Чем длиннее, тем лучше

Одним из используемых сейчас способов взлома компьютеров являются атаки Rainbow Table, использующие хеш-коды LM как уязвимости. Но более длинные пароли могут снизить эффективность атак Rainbow Table.

Я поражен, как много администраторов, занимающихся обеспечением безопасности, по-видимому, мало знакомы (или совсем незнакомы) с атаками Rainbow Table. Существуют различные способы создания атак Rainbow Table для различных алгоритмов. А они являются всего лишь предварительно вычисленным списком всех хеш-кодов LM из 0-14 символов.

Ограничением атак Rainbow Table является то, что злоумышленник должен в первую очередь получить хеш-коды LM. Это приводит к предыдущим вопросам о способах загрузки системы (с устройства чтения компакт-дисков или дисков DVD) и о том, являются ли пользователи локальными администраторами. В конечном счете, эти хеш-коды LM могут быть извлечены за несколько секунд с помощью бесплатных средств, например pwdump. Атаки Rainbow Table часто используются для поиска хеш-кодов, необходимых для определения пароля.

Чтобы удовлетворить мое любопытство, я установил пароль для встроенной учетной записи администратора системы. Пароль был длиной 14 символов и содержал различные строчные и прописные буквы, а также специальные символы и цифры. Затем я воспользовался бесплатно загруженной из Интернета программой для Rainbow Table и смог получить хеш-коды паролей для всех учетных записей в моей системе, а пароль администратора был определен менее, чем за две минуты.

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

Насилие домена

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

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

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

Теперь даже при присоединении рабочей станции или сервера к домену и после того, как служба Active Directory станет центральным хранилищем учетных записей, все локальные диспетчеры учетных записей безопасности (SAM) или локальные хранилища учетных записей не исчезают волшебным образом. Единственное, что происходит с этими локальными диспетчерами учетных записей безопасности, – это то, что они более не считаются защищенными и управляемыми, в чем и кроется проблема. Как вы в последний раз изменяли встроенную учетную запись администратора или пользователя root на ваших системах? А еще лучше загрузить какую-либо программу для работы с отчетами, которая может показывать срок действия паролей для всех учетных записей, а также то, пройдут ли результаты аудит.

Если вы все еще не очень понимаете, что я имею в виду, войдите на какую-либо из ваших рабочих станций, входящих в домен, с учетной записью домена с правами администратора. Откройте окно «Управление компьютером» системы и создайте локального пользователя ToldYouSo. Установите пароль для учетной записи и добавьте ее в локальную группу администраторов системы. Повторите этот процесс на другой системе домена.

Теперь войдите в какую-либо из этих двух систем с локальной учетной записью ToldYouSo и попытайтесь получить доступ ко второму компьютеру, перейдя по адресу \\systemName\c$. Вы получите доступ к административному общему ресурсу даже без запроса системы на ввод пароля! Надеюсь, это вас не удивляет. Но если это сюрприз для вас, запомните это и позвольте мне повторить: только то обстоятельство, что система принадлежит домену, не меняет факт, что все эти системы по-прежнему работают так, как будто принадлежит рабочей группе.

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

Извинения, извинения, извинения

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

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

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

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

Знали ли вы, что отключение встроенной учетной записи администратора в Windows не ведет к потере возможности входа в систему с этой учетной записью? Попробуйте следующее: перезапустите систему в безопасном режиме и войдите в нее со встроенной учетной записью администратора. Вероятно, можно успешно использовать пароль, выданный учетной записи исходным образом. Дополнительные сведения об этом поведении см. в статье «Как получить доступ к компьютеру после отключения учетной записи администратора» базы знаний Microsoft® (support.microsoft.com/kb/814777).

Требования нормативных органов

Удовлетворение требований SOX, PCI, HIPAA и других нормативных актов может поставить вас в тупик. Требования могут быть довольно трудными для понимания, поскольку они обширны и четко не определены. Как правило, все эти требования можно свести к следующему.

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

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

Автоматизированный подход

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

При использовании автоматизированных решений с возможностями управления и рандомизации этих паролей не следует выполнять только минимальные требуемые аудиторами действия. Например, зачем использовать для паролей всего 8 символов, когда можно использовать 15, 20 или 127, не затрачивая дополнительных усилий (см. рис. 2)?

Рис. 2. Автоматическое создание очень длинных паролей

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

Рис. 3. Ежедневная рандомизация привилегированных учетных записей

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

Подумайте об этом

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

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