Защитим права администратора!

Журнал "Windows 2000 Magazine" , #02/2000
Франклин Р. Смит

Знание слабых мест системы безопасности поможет предотвратить несанкционированный доступ

Доступ с правами администратора - голубая мечта взломщика компьютерных систем, поэтому именно о защите административных полномочий должен в первую очередь заботиться тот, кто отвечает за безопасность. Однако обеспечить надежную защиту административных учетных записей - значит не только просто правильно выбрать пароль. Некоторые особенности Windows NT, ошибки и неудачные параметры конфигурации по умолчанию образуют множество "дыр", через которые взломщик может проникнуть в систему. Системные администраторы настолько загружены, что часто еще больше усложняют проблему, используя широко распространенные, но ненадежные приемы администрирования. Знать слабые места в системе безопасности чрезвычайно важно для защиты и мониторинга административных учетных записей.

Уязвимость встроенной учетной записи администратора

В одной из своих статей я уже отмечал, что сама природа встроенной учетной записи Administrator делает NT уязвимой в отношении атак, направленных на "взлом" административной учетной записи. Нельзя просто взять и удалить эту всемогущую запись, так что злоумышленник знает наверняка, чей пароль нужно взламывать. К тому же по умолчанию NT не выполняет блокировку учетной записи Administrator после нескольких неудачных попыток регистрации, даже если установлен режим блокировки учетной записи после определенного числа таких попыток с помощью утилиты User Manager (команда Policy, Account). К счастью, положение можно исправить. Во-первых, нужно запустить утилиту Passprop с параметром /ADMINLOCKOUT (эта утилита из состава Microsoft Windows NT 4.0 Resource Kit впервые появилась в Service Pack 3). В результате на учетную запись Administrator будут распространяться те же ограничения установленной учетной политики, что и на остальные учетные записи.

Следующий шаг - переименовать учетную запись Administrator, чтобы лишить злоумышленника очевидной цели. Вместе с тем, если ограничиться простым переименованием, безопасность окажется мнимой. Например, известная программа RedButton использует анонимные соединения для перебора всех учетных записей и может найти переименованную учетную запись по ее идентификатору системы защиты SID, который никогда не меняется. Для защиты от подобного рода атак следует установить сервисный пакет SP3 и активизировать параметр реестра RestrictAnonymous. Нужно иметь в виду, что это действие может привести к некоторым проблемам в работе службы Computer Browser. После переименования встроенной учетной записи Administrator следует изменить поля Description и Full name, поскольку их значения по умолчанию раскроют истинную роль переименованной учетной записи. Многие системные администраторы идут еще дальше по пути маскировки встроенной административной учетной записи и создают учетную запись - "приманку". Эта запись не имеет никаких полномочий, но обладает всеми внешними атрибутами встроенной административной записи - в частности значениями по умолчанию в полях Description и Full name. Постоянный мониторинг процесса регистрации по данной учетной записи поможет выявить скрытые попытки проникновения в систему.

Ошибки

Ошибки кода операционной системы - еще одно уязвимое место защиты административных полномочий. В NT предусмотрено четкое разделение прикладных и системных процессов, что предохраняет систему от приложений - "диверсантов", которые пытаются найти лазейки в системе безопасности. Соответственно, имеется два режима работы программ. Приложения работают в пользовательском режиме, при котором запрещен доступ к произвольным областям памяти, аппаратуре и другим процессам. Операционная система работает в режиме ядра, и система ограничений здесь значительно слабее. Разделение режимов, в сочетании с другими характеристиками NT, должно было бы стать непреодолимой преградой на пути злоумышленника, но некоторые ошибки программного кода операционной системы все же дают о себе знать. Например, такие программы, как getadmin и sechole, могут предоставить непривилегированным пользователям полномочия администратора в любой системе, где есть возможность эти программы запустить. Другая ошибка в программном коде ОС приводит к тому, что пользователи могут повысить привилегии своей учетной записи посредством запуска специальной программы-заставки.

Пользователи то и дело находят все новые и новые ошибки, а Microsoft реагирует на их "открытия" выпуском соответствующих "заплаток". Использование программных "заплаток" - единственный способ защититься от ошибок в программном коде операционной системы и вызванной ими уязвимости системы безопасности. Тем, кто хочет быть в курсе последних новостей в этой области, советую подписаться на бюллетень по адресу: http://www.microsoft.com/security.

Уязвимость реестр

Злоумышленник может попытаться получить администраторские полномочия различными окольными путями, которые можно перекрыть простым изменением конфигурации и разрешений. Во-первых, в реестре есть несколько ключей, содержащих текст, интерпретируемый системой как команда, которую нужно запустить при регистрации пользователя. По умолчанию списки контроля доступа (Access Control List, ACL) для этих ключей слишком широки. Например, когда пользователь регистрируется в системе, NT проверяет раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Run, после чего исполняет каждое текстовое значение, содержащееся в ключе, как команду с привилегиями зарегистрировавшегося пользователя. Непривилегированный пользователь может добавить в этот раздел свои команды и дождаться, когда администратор зарегистрируется в системе. Когда это произойдет, команды, указанные злоумышленником, будут исполнены уже от имени администратора. Команды при этом могут делать все что угодно - от добавления взломщика в группу Administrators до изменения прав доступа к жизненно важным каталогам системы. По умолчанию группа Everyone имеет право Set Value в данном разделе. Очевидно, это право необходимо отменить. Имеются и другие разделы реестра, подвергающие риску систему защиты, хотя способ "взлома" в каждом конкретном случае может оказаться достаточно сложным. Полный список подобных разделов и рекомендации по их защите можно найти в работе признанного эксперта по вопросам безопасности NT Стива Саттона "Windows NT Security Guidelines" (http://www.trustedsystems.com).

Как и в случае с другими мерами по укреплению защиты, выполнение рекомендаций, связанных с повышением безопасности доступа к разделам реестра, может вызвать проблемы совместимости с плохо написанными приложениями, работа которых была рассчитана на незащищенную конфигурацию системы. Такие ситуации особенно часто возникают на рабочих станциях. Я бы рекомендовал в целях повышения безопасности уделить внимание прежде всего серверам и контроллерам доменов, которые должны по определению соответствовать более строгим требованиям в этом отношении, чем рабочие станции, в частности, и потому, что интерактивный запуск приложений на серверах и контроллерах доменов случается значительно реже. Файлы операционной системы в каталоге \%systemroot% (чаще всего C:\Winnt) с назначенными по умолчанию разрешениями также уязвимы для несанкционированных изменений. Непривилегированные пользователи могут заменить критически важные файлы операционной системы своими версиями, которые система будет исполнять в привилегированном режиме. Список каталогов, которые содержат подобные файлы, и рекомендованные изменения списков контроля доступа приведены в многочисленных публикациях (например, в упоминавшейся выше книге Стива Саттона "Windows NT Security Guidelines").

Защита реестра и каталогов операционной системы начинается с ограничения удаленного доступа к ним. С помощью одного-единственного раздела реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\SecurePipeServer\winreg можно указать, кто имеет право удаленного доступа к реестру (независимо от разрешений для конкретных разделов). Дополнительную информацию об ограничении удаленного доступа к реестру можно найти в статье "How to Restrict Access to NT Registry from a Remote Computer" (http://support.microsoft.com/support/kb/ articles/q153/1/83.asp). Важно убедиться, что пользователи не могут получить удаленный доступ к каталогам операционной системы благодаря неосторожно созданным общим ресурсам. Следуя приведенным выше простым рекомендациям, можно ограничить круг лиц, способных внести изменения в реестр и файловую систему.

Службы

Существует еще один способ защиты административных учетных записей. Он потребует особого внимания к службам, доступным обычным пользователям. Многие системные службы, например планировщик задач или сервер баз данных, предоставляют в распоряжение пользователей механизмы запуска команд, исполнять которые будет сама служба. Некоторые планировщики достаточно "умны" и умеют выполнять команды от имени учетной записи пользователя. Другие этого делать не умеют, и команда выполняется с привилегиями учетной записи самой службы. Например, в состав Microsoft SQL Server входит собственный планировщик задач и SQL-команд, что дает пользователям SQL Server возможность выполнять команды операционной системы. В этом случае существует два способа защиты администраторских полномочий. Во-первых, можно ограничить права пользователей на выполнение команд настройкой самой службы. Большинство служб, таких, как SQL Server и Microsoft Exchange Server, снабжены механизмами аутентификации и контроля доступа. Необходимо убедиться, что такие механизмы корректно сконфигурированы, и следить за их настройкой. Во-вторых, зачастую подобные службы запускаются от имени системной учетной записи Local System Account, которая даже мощнее, чем учетная запись администратора системы. Чтобы этого избежать, нужно создать отдельную учетную запись для службы и предоставить ей только те права и разрешения, которые необходимы для работы. В результате если кто-то и получит возможность работать с данной службой, то у него будут лишь те права доступа к системе, которые предоставлены учетной записи службы.

Такой подход особенно важен применительно к системной службе планировщика NT Scheduler. По умолчанию эта служба работает от имени системной учетной записи. Если это не имеет значения, ее можно запускать от имени непривилегированного пользователя. В любом случае следует иметь в виду, что члены группы Server Operators могут выполнять команды с помощью NT Scheduler, лишь когда значение реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\LSA\SubmitControl равно 1. Запуск NT Scheduler от имени системной учетной записи или пользователя с административными привилегиями фактически означает, что члены группы Server Operators могут повысить собственные привилегии до уровня администратора системы. Здесь важно убедиться, что значение ключа реестра SubmitControl равно 0.

И последнее замечание относительно конфигурации системных служб: следует помнить о том, что NT уязвима с точки зрения физического доступа. Если злоумышленник сможет загрузить компьютер под управлением DOS или другой операционной системы, он получит неограниченный доступ к системе. Использование пароля на уровне BIOS ограничит возможность локальной загрузки и модификации параметров CMOS. Однако не нужно полностью полагаться только на такую защиту. Взломщик может обойти все подобные уловки, сбросив BIOS, удалив батарейки или просто изъяв из компьютера жесткий диск. Известно, что в Internet можно найти заводские пароли для многих моделей BIOS. Лучшая защита - держать сервер, ленты с резервными копиями данных и диски аварийного восстановления под замком.

Рекомендации администраторам

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

Я не рекомендую использовать встроенную учетную запись Administrator в ежедневной работе. Поскольку эта запись - первая цель злоумышленников, ею лучше пользоваться для отслеживания попыток проникновения в систему. Если активизировать аудит регистрации пользователей и воздерживаться от применения учетной записи Administrator, можно быстро обнаружить активное зондирование этой учетной записи в журнале безопасности системы (Event ID 528 - успешная регистрация, Event ID 529 - ошибка регистрации).

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

Еще одно важное правило для администраторов: зарегистрировавшись в системе по учетной записи с административными полномочиями, не следует запускать программу, к которой нет полного доверия. Администратор, запускающий такую программу, подобен офицеру, выполняющему приказ на запуск баллистической ракеты без проверки подлинности приказа. Однако претворить эту рекомендацию на практике куда сложнее, чем ее декларировать, если принять во внимание постоянно изменяющуюся вычислительную среду и повсеместный доступ в Internet. Web-браузер, к примеру, вовсе не та программа, которой следует безоговорочно доверять, а значит, зарегистрировавшись с правами администратора, надо быть начеку. К сожалению, электронная почта - также небезопасное средство с этой точки зрения. Некоторые недавние случаи наглядно продемонстрировали способность злоумышленников выполнить произвольный код на чужой машине с помощью простого электронного письма. В одном случае злоумышленник спровоцировал переполнение буфера в среде Microsoft Outlook 98 при обработке присоединенных к письму файлов. Аналогичные последствия могут возникнуть и в таких приложениях, как Microsoft Word и Microsoft Excel, в связи с быстрым распространением макровирусов.

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

Вероятно, читатели удивлены: как же можно отказаться от использования Web-браузера, электронной почты и других приложений и продолжать выполнять свою работу. Многие администраторы то и дело переключаются между окном User Manager for Domains и программой электронной почты или другими приложениями. А значит, довольно сложно следовать обозначенному выше правилу: никогда не запускать ненадежные программы. К счастью, в состав программного пакета Resourсe Kit входит замечательная утилита SU, диалоговое окно которой показано на Экране 1. Она позволяет запускать любую программу от имени любой указанной учетной записи, так что можно зарегистрироваться в системе по одной учетной записи, а приложения запускать от имени другой. Для защиты своих административных привилегий стоит взять за правило регистрироваться в системе по непривилегированной учетной записи и запускать обычные приложения - текстовый редактор, Web-браузер - привычными значками рабочего стола. Тогда любой опасный для системы злонамеренный код будет выполняться от имени ограниченного в правах непривилегированного пользователя. Кроме того, нужно создать значки для таких приложений, как User Manager for Domains и Server Manager, которые следует запускать от имени пользователя с привилегиями администратора, и воспользоваться утилитой SU для запуска соответствующих приложений. Единственное неудобство, с которым предстоит столкнуться, заключается в необходимости каждый раз вводить пароль для регистрации с правами привилегированного пользователя.

Серверы и рабочие станции домена

экран 1. Использование утилиты SU.

Регулярный мониторинг параметров системы безопасности серверов и рабочих станций домена, на которых работают сотрудники, имеющие доступ к критически важным ресурсам, - важнейший аспект защиты домена, поскольку эти системы также могут стать мишенью для тех, кто хочет завладеть правами администратора. Каждый такой сервер и рабочая станция хранят локальную копию базы учетных данных, которая служит для назначения пользователям локальных прав и определения их принадлежности к той или иной локальной группе. Многие дополнительные привилегии пользователей, например Act as part of the operating system, а также привилегии, относящиеся к управлению маркерами доступа, позволяют злоумышленнику захватить управление системой и получить доступ к административным привилегиям. Встроенные локальные группы Administrators и Power Users также имеют в системе особые привилегии.

И, наконец, важно убедиться в том, что за развертывание рабочих станций отвечают достаточно компетентные сотрудники. Эту задачу зачастую выполняют либо начинающие, либо контрактники, а поскольку именно они устанавливают операционную систему, они выбирают и пароль для встроенных административных учетных записей. Многие пользователи не подозревают о существовании встроенной учетной записи Administrator, а большинство администраторов забывают об этом, как только рабочая станция установлена. По умолчанию на рабочей станции NT активизируется служба Server, и станция может функционировать как файловый сервер. Должны ли посторонние специалисты или младший технический персонал иметь возможность доступа с правами администратора к рабочей станции после того, как она передана в распоряжение того или иного пользователя? Скорее всего, нет, но часто это происходит именно так - все зависит от методики развертывания рабочих мест, принятой в организации. Допустим, младший IT-специалист, проработавший в компании всего лишь несколько месяцев, имеет доступ к рабочей станции вице-президента по маркетингу или вице-президента по персоналу. Именно такую картину я нередко наблюдал в организациях, куда меня приглашали для анализа системы защиты. Подобные рабочие станции - настоящий клад для злоумышленника, поскольку на локальных дисках приложения кэшируют временные файлы, а пользователи хранят конфиденциальную информацию, несмотря на требования поступать наоборот. Не стоит облегчать взломщикам жизнь, позволяя им с легкостью проникнуть в систему. Советую сбросить пароль учетной записи Administrator на серверах и рабочих станциях домена и рассмотреть возможность отключения службы Server.

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