Настройки безопасности в Windows

Тонкая настройка брандмауэра Windows Firewall в Windows XP SP2
Девять новых параметров Group Policy и соответствующие команды.
Рассмотрим девять новых параметров Group Policy для Windows Firewall и соответствующие команды. Параметры Windows Firewall хранятся в папке Computer Configuration\Administrative Templates\Network\Network Connections\Internet Connection Firewall. В этой папке существует две подпапки: Domain Profile и Mobile Profile. Параметры политики Domain Profile активизируются на компьютере с установленным Windows Firewall, когда данный компьютер регистрируется в домене; в противном случае выбираются параметры Mobile Profile. Обе подпапки содержат одинаковый набор из девяти параметров политики.
В предыдущей статье речь шла о первом параметре, Operational Mode. Данный параметр обеспечивает три режима: Disabled отключает брандмауэр, Protected активизирует брандмауэр, а Shielded активизирует брандмауэр, но компьютер оказывается более изолированным от сети, чем в режиме Protected, который позволяет открыть определенные порты. Чтобы перевести компьютер в режим Disabled, Protected или Shielded, следует воспользоваться командой

netsh firewall ipv4 set opmode

с ключом disabled, enabled или shield. Обозначения в командной строке иногда отличаются от названий соответствующих параметров Group Policy. Таким образом, чтобы надежно защитить сетевой адаптер, следует ввести команду

netsh firewall ipv4 set opmode shield

Эту команду удобно использовать в командном файле. Можно создать для командного файла ярлык на рабочем столе, назвав его Shield this System, чтобы можно было дважды щелкнуть на нем при любых признаках опасности для сети. С помощью команды

netsh firewall ipv4 show opmode

можно узнать режим брандмауэра.
Изменение параметров брандмауэра
Свойства следующего параметра политики Windows Firewall - Allow User Preference/Group Policy Settings Merge не совсем ясны. В документации Windows Firewall указывается, что с помощью данного параметра локальные администраторы могут изменить режим брандмауэра. Но что означает слово "изменить" - включить или выключить брандмауэр либо настроить его, открывая и закрывая порты? В данном случае "изменить" имеет второе значение: с помощью данной политики локальный администратор может открыть или закрыть порт, но не отменить режим Disabled, Protected или Shielded, установленный доменной политикой (предполагается, что доменная политика для Windows Firewall существует). Если в политике задан режим Disabled, то локальный администратор не может управлять работой брандмауэра.
Путаница начинается, если локальный администратор пытается отменить параметры Windows Firewall, заданные объектом Group Policy Object (GPO). В ответ на команду

netsh firewall ipv4 set opmode disable

будет получен результат OK, и следующая команда Netsh Firewall сообщит, что брандмауэр отключен. Однако, заглянув в свойства сетевого адаптера в папке Network Connections, можно увидеть, что брандмауэр активен. Несколько тестов показывают, что информация графического интерфейса соответствует действительности: преобладают доменные параметры. Будем надеяться, что в окончательной версии эти недостатки будут исправлены.
Однако нельзя всегда полагаться на диалоговые окна. Если присвоить параметру Allow User Preference/Group Policy Settings Merge значение Disabled, то цвет окна становится серым, а переключатели для активизации и отключения Windows Firewall перестают действовать. Такой подход разумен. Но попробуйте активизировать параметр, а затем вернуться к экрану настройки Windows Firewall. Кнопки для включения и выключения брандмауэра доступны. Если щелкнуть на одной из них, а затем на OK, то на экране не появится сообщения об ошибке, но и изменений также не произойдет. Однако локальный администратор может открывать и закрывать порты с помощью командной строки или gpedit.msc. Для параметра политики Allow User Preference/Group Policy Settings Merge эквивалента командной строки не существует.
Открываем порты для программ
Следующий параметр политики - первый из семи параметров, с помощью которых можно открыть или (в некоторых случаях) закрыть конкретный порт. Открывая брандмауэр для прохождения определенного типа трафика (например, Web-трафика, данных аутентификации Active Directory или загрузки электронной почты), трудно определить, какой порт необходим для этого типа трафика. Задача упрощается благодаря параметру политики Define Allowable Programs. По умолчанию Windows Firewall блокирует непрошеный входящий трафик, но не исходящий. Такой подход приемлем, если рабочая станция функционирует как клиент, инициирующий обмен данными (например, запрашивая почтовый сервер о наличии сообщений или Web-сервер - об информации). Но он не срабатывает, если рабочая станция предоставляет службы другим компьютерам сети, например, если на рабочей станции размещен почтовый сервер, потому что брандмауэр блокирует попытки клиентов инициировать диалог с серверной программой. Он также непригоден для одноранговых (peer-to-peer, P2P) соединений, таких как Instant Messaging (IM), в которых две или несколько машин обмениваются данными, выполняя обязанности и клиентов, и серверов одновременно. Таким образом, для запуска сервера или организации соединений P2P необходимо открыть некоторые порты.
Но какие именно порты следует открыть? Для ответа на этот вопрос достаточно указать конкретную программу в параметре Define Allowable Programs, и Windows Firewall открывает порты, необходимые данной программе. Пользователь указывает в параметре политики местонахождение программы, определяет ее состояние (активное или блокированное; например, можно составить политику блокирования портов для конкретной программы, если эта программа была "троянским конем", проникшим в сеть) и открывает соответствующие порты для всего Internet или только для локальной подсети.
Предположим, что на компьютере работает серверная программа C:\myprogs\serverprog.exe. Неизвестно, какие порты она открывает, но необходимо, чтобы эти порты были открыты только для компьютеров той подсети, в которой расположен сервер. Нужно активизировать параметр Define Allowable Programs, затем щелкнуть на кнопке Show, чтобы на экране появилось диалоговое окно для ввода информации о почтовом сервере. В этом диалоговом окне я ввел строку

C:\myprogs\serverprog.exe:LocalSubnet:
enabled:E-mail server

которая определяет четыре компонента, каждый из которых отделен от остальных двоеточием. Первый компонент - полный путь к программе. Можно использовать переменные среды, такие как %ProgramFiles%. Следующий компонент, LocalSubnet, указывает на необходимость принять трафик, входящий в порты этого сервера только из систем той же подсети. Третий компонент, enabled, разрешает прохождение трафика. И четвертый компонент, E-mail server, представляет собой просто метку, которую Windows Firewall может использовать при составлении отчетов. Число программ не ограничено.
Открытие конкретных портов
С помощью остальных параметров открываются различные порты. Не совсем ясно, следует ли активизировать первый из них, Allow Dynamically Assigned Ports for RPC and DCOM. Вообще я предпочитаю инструменты на основе Windows Management Instrumentation (WMI), такие как WMI VBScripts и оснастка Manage Computer консоли Microsoft Management Console (MMC), но для WMI необходимы вызовы удаленных процедур (Remote Procedure Calls, RPC). Оснастку Manage Computer нельзя использовать для дистанционного управления системой без WMI, поэтому, чтобы управлять удаленными системами с помощью Manage Computer при активном Windows Firewall, необходимо активизировать этот параметр. Опасность открывания портов для RPC заключается в том, что за последние два года в RPC было обнаружено несколько серьезных ошибок, одна из которых привела к памятной атаке MSBlaster. Поэтому активизация брандмауэра при открытых портах для RPC - противоречивое решение; с таким же успехом можно запереть на замок все двери в доме, ради удобства (своего и грабителей) оставив открытым парадный вход. Как и предыдущий, данный параметр позволяет открыть порты для всех IP-адресов или только для локальной подсети, но такой вариант тоже не очень удачен. Во многих случаях вирус MSBlaster распространялся от зараженного компьютера, который кто-то приносил на предприятие. Поэтому перед активизацией данного параметра необходимо тщательно все обдумать.
Как и RPC, параметры File and Print Sharing, Remote Assistance Support и Universal Plug and Play можно отменить или активизировать, а действие активных параметров ограничить локальной подсетью. Все эти параметры, кроме Remote Assistance Support, можно активизировать из командной строки с помощью команды

netsh firewall ipv4 set service

за которой следует type= и имя службы (например, FILEANDPRINT, RPCANDDCOM или UPNP) или scope= с последующими ключами all (для всех IP-адресов) и subnet (для локальной подсети). Например, чтобы разрешить совместную работу с файлами и принтерами только в локальной подсети, следует ввести команду

netsh firewall ipv4 set service
type=fileandprint scope=subnet

Любую команду можно дополнить ключами profile= и interface=, поэтому, если файл- или принт-службу требуется открыть для проводного Ethernet-соединениия только в случаях, когда система подключена к домену, нужно ввести команду

netsh firewall ipv4 set service
type=fileandprint scope=subnet interface="local area connection" profile=corporate

Group Policy работает с профилями Domain и Mobile, а инструменты командной строки - с корпоративными и другими профилями.
Остается два параметра политики. Allow ICMP Settings воздействует на подсистему ICMP (Internet Control Message Protocol - протокол управления сообщения Internet). В сущности, для администратора важен лишь один компонент ICMP: Ping. По умолчанию в системах с брандмауэром блокируются все запросы ICMP, и потому сигналы эхо-тестирования игнорируются. В Allow ICMP Settings Properties перечислено девять типов запросов ICMP, разрешенных брандмауэром Windows Firewall. Для тестирования нужно активизировать только запрос Allow Inbound Echo Request. Данный параметр не позволяет ограничить ICMP-трафик локальной подсетью.
ICMP открывается из командной строки:

netsh firewall ipv4 set icmpsetting

с последующим ключом type= и числом (3, 4, 5, 8, 10, 11, 12, 13 или 17) или словом all. Номер указывает один из девяти параметров ICMP, и нам нужен номер 8 - входящий запрос (incoming echo request). Чтобы машина отвечала на сигналы тестирования, необходимо ввести команду

netsh firewall ipv4 set icmpsetting type=8

Команду можно уточнить с помощью ключей profile= и interface=.
Как открыть порт для службы, которая в данной статье не рассматривалась? Для этого можно воспользоваться девятым параметром политики, Define Custom Open Ports. Затем следует указать номер порта Windows Firewall, тип порта (TCP или UDP), область действия (все IP-адреса или только локальная подсеть) и действие (активизировать или блокировать). При желании порту можно присвоить описательное имя. Например, для почтового сервера можно открыть всему миру порт TCP 25:

25:TCP:*:enabled:SMTP

где 25 - номер порта, TCP - протокол, звездочка (*) открывает порт всему миру (не только подсети), ключ enabled открывает, а не закрывает порт, и SMTP - описательная фраза. В командной строке нужно ввести

netsh firewall ipv4 add portopening

с последующими ключами protocol= (варианты - tcp, udp или all), port= (с номером), name= (с именем), mode= (enable или disable) и scope= (all или subnet). Для активизации почтового сервера следует ввести команду

netsh firewall ipv4 add portopening
protocol=tcp port=25 name=SMTP mode=enable scope=all

Если режим не указан, то подразумевается enable (активизирован), а если не указан диапазон scope - подразумевается subnet (подсеть).
Чтобы закрыть порт, достаточно ввести команду

netsh firewall ipv4 delete portopening

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

netsh firewall ipv4 delete portopening
protocol=tcp port=25

В процессе экспериментов могут возникнуть недоразумения - порт был закрыт, но почему-то остается открытым. Чтобы избежать недоразумений, следует уяснить разницу между поведением брандмауэров, управляемых параметром Group Policy и с помощью командной строки. Команды, подаваемые из командной строки, обычно вступают в силу немедленно. Изменения в Group Policy начинают действовать спустя некоторое время. Чтобы изменения Group Policy для Windows Firewall вступали в действие сразу же, следует применить команду gpupdate.
Необходимо дождаться, пока обработка команды завершится, затем перейти к функции Services в оснастке Manage Computer и перезапустить службу Internet Connection Firewall (в окончательной версии имя службы может быть изменено).
Дополнительные возможности командной строки
Мы рассмотрели возможности параметров Group Policy для Windows Firewall, но функции командной строки шире. Следует помнить, что Windows Firewall имеет два профиля: Domain и Mobile. Предположим, нам нужно выяснить, какой профиль используется в данный момент. Следующая команда показывает активный профиль - Domain Profile (corporate) или Mobile Profile (other):

netsh firewall ipv4 show currentprofile

Команда Set Logging позволяет больше узнать о работе брандмауэра. Она имеет четыре факультативных параметра: Filelocation= показывает брандмауэру, куда записать ASCII-файл журнала, а maxfilesize= задает максимальный размер файла. Размер файла указывается в килобайтах, и максимальное допустимое значение - 32767. Параметры droppedpackets= и connections= принимают значения enable или disable и указывают брандмауэру, следует ли регистрировать блокированные и успешные соединения. Например, чтобы записывать как успешные, так и блокированные соединения в файле C:\firelog.txt размером максимум 8 Мбайт, нужно ввести команду

netsh firewall ipv4 set logging
filelocation="C:\firelog.txt" maxfilesize=8192 droppedpackets=enable connections=enable

Журнал может быть большим, но если нужно обнаружить взломщика, регулярно предпринимающего попытки атак, полезно иметь полный журнал, в котором отражены все соединения и отказы TCP и UDP. Задать текущий режим регистрации можно с помощью команды

netsh firewall ipv4 show logging

Следующая команда выдает исчерпывающий список параметров брандмауэра:

netsh firewall ipv4 show config

Заменив в данной команде ключ config ключом state, можно получить подробные сведения о действиях, выполняемых брандмауэром. Чтобы получить более компактный отчет, содержащий только информацию об открытых портах, следует заменить config на icmpsetting или portopening.
Для работы с Windows Firewall требуется освоить много новых понятий. Однако если в системе персонального брандмауэра нет, то Windows Firewall поможет защитить машину, придется лишь потратить незначительное время на создание GPO, чтобы открывать нужные порты. Вознаграждением для администратора будет сознание того, что система за брандмауэром станет куда менее уязвимой.

09.02.2003 WiNTик с секретом
Windows NT/2000 — это единственное семейство операционных систем Microsoft, в котором с начального момента разработки было уделено должное внимание требованиям безопасности. Изначально была поставлена задача создать операционную систему, соответствующую требованиям уровня защищенности С2 — набора критериев, разработанного Национальным агентством США по безопасности (U.S. National Security Agency, NSA), в соответствии с которыми выполняется оценка защищенности компьютеров и работающего на них программного обеспечения.
Требования к операционной системе, защищенной по классу С2, включают:
обязательную идентификацию и аутентификацию всех пользователей операционной системы. Под этим понимается способность операционной системы идентифицировать всех пользователей, которые получают санкционированный доступ к системе, и предоставление доступа к ресурсам только этим пользователям;
разграничительный контроль доступа — предоставление пользователям возможности защиты принадлежащих им данных;
системный аудит — способность системы вести подробный аудит всех действий, выполняемых пользователями и самой операционной системой;
защита объектов от повторного использования — способность системы предотвратить доступ пользователя к информации ресурсов, с которыми до этого работал другой пользователь (например, обеспечение невозможности повторного использования освобожденной памяти или чтения информации из файлов, которые были удалены).
В процесс сертификации операционной системы по уровню защищенности С2 входят:
исследование исходного кода;
изучение документации о подробностях реализации, предоставленной разработчиками;
повторное тестирование с целью устранения всех ошибок, выявленных в ходе оценки.
2 декабря 1999 года правительство США объявило, что операционные системы Windows NT 4.0 Workstation и Windows NT 4.0 Server успешно прошли сертификацию по классу С2.
Что касается операционных системах из семейства Windows 2000, то говорить о защищенности по классу С2 пока еще рано — им процедура сертификации еще предстоит.
Разумеется, случаи несанкционированного вмешательства в работу компьютерных сетей — реальность сегодняшней жизни. Но гораздо более распространен случай, когда вред (причем неумышленный!) наносят пользователи, знающие недостаточно много, чтобы быть грамотными, но достаточно, чтобы представлять угрозу. Практически в каждой организации имеются любители запускать все исполнительные файлы подряд. Если им попадается на глаза один из редакторов реестра — Regedit.exe или Regedt32.exe, а меры по безопасности не приняты, то они могут мучить его до тех пор, пока не начнутся проблемы с загрузкой системы.
Обзор стандартных прав доступа в Windows 2000
Стандартные настройки системы безопасности Windows 2000 определяются правами по умолчанию, которые назначаются следующим группам:
Administrators (Администраторы) — пользователи этой группы обладают всеми правами на локальном компьютере или в домене;
Power Users (Опытные пользователи) — эта группа обладает правами, набор которых меньше, чем набор прав членов группы Administrators, но существенно шире, чем права, предоставленные группе Users.
Users (Пользователи) — при условии, что новая копия Windows 2000 (в отличие от случаев, когда производится обновление версии операционной системы) была установлена на разделе NTFS, стандартная настройка системы безопасности сконфигурирована так, что пользователям из группы Users не позволяется нарушать целостность операционной системы и установленных приложений. Пользователям из этой группы не дозволено устанавливать приложения, которые могут использоваться другими членами этой группы (это одна из мер защиты против «троянских коней»). Помимо этого, пользователи не могут получить доступ к данным других пользователей. Таким образом, для построения защищенной системы Windows 2000 Microsoft рекомендует конфигурировать систему таким образом, чтобы все конечные пользователи были членами только одной группы — Users, а приложения, необходимые для работы, устанавливать так, чтобы их мог запускать любой член группы Users.
Общие рекомендации по защите...
Microsoft официально рекомендует администраторам ограничивать доступ пользователям к целому ряду вложенных ключей, входящих в состав ключа HKLM\SOFTWARE. Основная цель этих операций заключается в предотвращении доступа неквалифицированных пользователей к параметрам настройки установленного в системе программного обеспечения.
Microsoft официально рекомендует ограничивать доступ к следующим ключам реестра:
HKLM\SOFTWARE\ Microsoft\Windows NT\CurrentVersion;
HKLM\SOFTWARE\ Microsoft\Windows \CurrentVersion;
для группы Everyone достаточно иметь права доступа Query Value, Enumerate Subkeys, Notify и Read Control к ключу реестра HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion и следующим вложенным подключам, имеющимся в его составе: AeDebug, Compability, Drivers, Embedding, Font Drivers, FontCache, FontMapper, Fonts, FontSubstitutes, GRE_Initialize, MCI, MCI Extensions, Ports (и всем вложенным ключам в составе ключа Ports), Type 1 Installer, Windows 3.1 MigrationStatus (и всем вложенным ключам в составе этого ключа), WOW (вложенным ключам в составе этого ключа);
Microsoft также рекомендует ограничить доступ пользователей к ключу реестра, управляющему данными о производительности системы — это ключ HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion\Perflib. Доступ к этому ключу должны иметь только операционная система (System), создатели ключа (Creator owner), члены группы Administrators и пользователи, зарегистрировавшиеся в системе интерактивно (Interactive).
Группа Everyone должна иметь ограниченные права доступа (только права типа Query Value, Enumerate Subkeys, Notify, Read Control) и к некоторым другим ключам реестра. Такую защиту необходимо обеспечить для ключа HKEY_CLASSES_ROOT и для всех его вложенных ключей, а также для HKEY_USERS\.DEFAULT. Защищая эти ключи, вы защищаете систему от изменения ряда системных параметров и параметров настройки рабочего стола.
Чтобы предотвратить несанкционированное использование разделяемых ресурсов системы и применения параметра ImagePath в составе ключа UPS для запуска нежелательного программного обеспечения, доступ типа Full Control к ключам HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\LanmanServer\Shares и HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\UPS следует оставить лишь за операционной системой (System) и членами группы Administrators.
При работе с сервисом удаленного доступа система выводит диалоговые окна, в которых пользователи должны ввести регистрационную информацию — входное имя и пароль. В этих диалоговых окнах имеются флажки, установка которых позволяет запомнить пароль. Хотя сохранение паролей очень удобно для конечного пользователя, эта практика представляет собой определенную опасность, поскольку пароли хранятся так, чтобы система могла быстро их извлечь. Таким образом, извлечь этот пароль несложно и взломщику.
Для того чтобы не дать такой возможности потенциальному взломщику, раскройте ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\RemoteAccess\Parameters и добавьте в него параметр DisableSavePassword с типом данных REG_DWORD. Теперь система никогда не будет предлагать пользователю сохранить введенный пароль для доступа к серверу RAS.
Защита ульев SAM и Security.
Информация о безопасности Windows NT/2000 хранится в ветвях реестра SAM (Security Accounts Manager) и Security. Ветвь SAM содержит пользовательские пароли в виде таблицы хэш-кодов, а ветвь Security — информацию о безопасности локального компьютера.
Microsoft официально утверждает, что лучший способ защиты Windows NT/2000 — это защита административных паролей, но этого явно недостаточно. Доступ к ветвям SAM и Security получают многие пользователи — например, пользователи из группы Backup Operators. Ветви SAM и Security хранятся на диске наряду с другими файлами, и единственное, что требуется для взлома — это раздобыть копии этих ульев. В составе программных продуктов имеются утилиты (Regback в WinNT 4.0 Resource Kit и REG — в Windows 2000 Resource Kit), при помощи которых пользователи, принадлежащие к группам администраторов или операторов резервного копирования, могут получать копии реестра работающей системы.
Если WinNT/2K установлена на томе FAT, то потенциальную опасность представляют любые пользователи, обладающие правом на выполнение перезагрузки системы и получившие физический доступ к компьютеру.
Наибольшую ценность для взломщика представляют сервера компьютерной сети. Поэтому для обеспечения должной защиты файлов SAM и Security от незаконного копирования следует установить защищаемые компьютеры (сервера) в охраняемом помещении, а также лишить пользователей групп (Advanced Users and Users) права на перезагрузку компьютера.
Чтобы отредактировать права пользователей в Win2K, зарегистрируйтесь в системе от имени пользователя с правами администратора, раскройте окно Control Panel, выполните двойной щелчок мышью на значке Administrative Tools и выберите опцию Local Security Policy. Разверните дерево консоли MMC и выберите опцию User Rights Assignment. В правой части окна появится список пользовательских прав, доступных для редактирования.
Для предотвращения доступа рядовых пользователей домена к файлам SAM и Security следует:
использовать файловую систему NTFS;
лишить конечных пользователей права локальной регистрации на серверах;
обеспечить надлежащую физическую защиту для серверов;
в системах WinNT4.0 и тех системах Win2K, где операционная система устанавливалась как обновление предыдущей версии WinNT, следует ужесточить права доступа к каталогу %SystemRoot%\Repair;
обеспечить безопасные условия хранения резервных копий и дисков аварийного восстановления (WinNT4.0), а также копий данных из набора System State Data (Win2K).
Для взлома похищенных ульев SAM и Security больших усилий не требуется. Успех проведенной атаки зависит в основном от качества используемого для взлома словаря — чем больше количество слов, дат, чисел, словосочетаний, используемых чаще всего в качестве пароля, содержится в этом файле, тем выше шансы удачного взлома.
Для защиты каталога \repair назначайте права таким образом, чтобы злоумышленники не могли получить доступ к данному каталогу и содержащимся в нем файлам, в особенности к файлу sam._, в котором находится база данных SAM. Если вы используете Microsoft Windows NT Server 4.0, то чтобы защитить файлы в каталоге \repair, используйте утилиту calcs.exe, входящую в состав Microsoft Windows NT Server 4.0 Resource Kit или другую аналогичную программу. Для этого выполните следующее.
В окне Command Prompt перейдите в каталог %systemroot% (обычно это C:\winnt) и выполните команду:
cacls repair /g administrators:F system:F /t Либо, используя программу Windows Explorer, можете сделать следующее:
Откройте Windows Explorer;
Перейдите в каталог repair (обычно это C:\winnt\repair), нажмите правую клавишу мыши и выберите в открывшемся меню Properties;
Выберите закладку Security;
Выберите Permissions;
Отметьте Replace Permissions on Subdirectories и Replace Permissions on Existing Files;
Удалите из списка всех пользователей, кроме Administrators и SYSTEM;
Убедитесь, что и Administrators, и SYSTEM имеют права Full Control;
Нажмите OK.
Теперь вы назначили пользователям Administrators и SYSTEM права Full Control на данный каталог и все файлы, которые в нем содержатся. Поскольку режим редактирования ACL выбран не был, права всех остальных пользователей удалены системой.
В зависимости от конфигурации системы, помимо каталогов \repair и \config, NT может записывать информацию, имеющую отношение к SAM, в следующие файлы: pagefile.sys, memory.dmp или user.dmp. NT использует файл pagefile.sys как дополнительное пространство для организации виртуальной памяти, которое добавляется к физической памяти, установленной в компьютере. Файл memory.dmp создается при аварийном завершении работы операционной системы, если в конфигурации NT выбран режим записи образа памяти на диск. Файл user.dmp создается при аварийном завершении работы какой-либо прикладной программы, если в конфигурации программы Dr. Watson выбран режим записи образа памяти в файл.
При работе с этими файлами NT переписывает определенную порцию данных с памяти на диск. В некоторых случаях эти данные могут содержать пароли, хранящиеся резидентно в памяти. Соответственно, получив доступ к этим файлам, взломщик может без особого труда завладеть важной информацией, позволяющей пробить брешь в системе безопасности.
Чтобы уменьшить опасность, связанную с использованием файлов user.dmp и memory.dmp, вам необходимо предпринять одно из следующих действий:
написать командный файл, который будет удалять указанные файлы при входе в систему;
установить права для этих файлов так, чтобы только администраторы могли иметь доступ к ним.
установить в реестре ключ, указывающий на необходимость удаления системного файла pagefile при завершении работы операционной системы.
в конфигурации программы Dr. Watson отключить режим создания файлов.
Лучше всего настроить параметры системы так, чтобы указанные два файла не создавались. Но тогда программисты, которые должны исследовать проблему аварийного завершения работы системы, не смогут обладать необходимыми им данными.
Чтобы отключить создание файлов user.dmp программой Dr. Watson, запустите утилиту drwtsn32.exe, отключите параметр Create Crash Dump File и закройте программу.
Чтобы отключить в параметрах настройки NT создание файла memory.dmp, запустите в Панели Управления (Control Panel) программу System и выберите закладку Startup/Shutdown.
Затем отключите параметр Write debugging information to. Если вам все же необходимо иметь образы памяти на момент аварийного завершения работы NT, постарайтесь настроить параметры ОС и программы Dr. Watson таким образом, чтобы файлы, содержащие образ памяти, помещались в защищенный каталог, доступный только администраторам.
Что касается файла pagefile.sys, то его открывает и защищает от попыток непосредственного доступа со стороны взломщиков только операционная система. Однако следует упомянуть прошлогодний инцидент, когда клиентская служба NetWare для WindowsNT помещала в память пароли пользователей NetWare в открытом виде. Эти пароли могли быть записаны в файл pagefile.sys при переписывании соответствующей страницы памяти на диск. Любой человек, имеющий копию файла pagefile.sys и текстовый редактор, мог без труда получить пароли. Разработчики Novell решили эту проблему. Теперь прежде чем поместить пароли в pagefile, они шифруются с использованием недокументированного API-интерфейса. Однако взломщики могут пробить эту защиту. Так, изобретательные российские программисты нашли способ расшифровки информации, получаемой из файла pagefile.sys. Чтобы защититься от подобных атак, настраивайте NT таким образом, чтобы файл pagefile.sys удалялся при завершении работы системы. И не забывайте о необходимости физической защиты компьютера с целью предотвращения нежелательного доступа к файлу pagefile.sys.
Да, вы можете сконфигурировать NT так, чтобы pagefile удалялся при нормальном завершении работы системы. Но таким способом вы обеспечите защиту только от тех взломщиков, которые копируют или изменяют файл, загрузившись с другой копии ОС (т.е. используя загрузочный диск или загрузив NT из другого системного каталога). Большинство взломщиков понимают, что в таком случае у них есть возможность получения доступа к системе путем перемещения базы данных SAM, следовательно, взлом файла pagefile.sys становится бессмысленным
Несмотря на это, в ситуациях, когда условия эксплуатации системы требуют установки и использования нескольких копий ОС, удаление файла pagefile при нормальном завершении работы можно считать достаточной мерой безопасности. Следует иметь в виду, что если NT сконфигурирована так, чтобы удалять pagefile во время завершения работы системы, то неизбежна некоторая задержка в процессе начальной загрузки и останова ОС. Однако эта задержка несущественна, если принять во внимание уровень безопасности, которого мы в результате достигаем. Для того чтобы включить режим удаления файла pagefile.sys во время нормального завершения работы ОС, следует модифицировать (или создать) в системном реестре параметр ClearPageFileAtShutdown (типа REG_SZ) в ключе HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Session Manager\Memory Management, присвоив ему значение 1.

Хэш-коды паролей в памятиПо умолчанию NT кэширует необходимые для регистрации атрибуты для 10 последних пользователей, входивших в систему интерактивно. Это делается для того, чтобы пользователь смог зарегистрироваться, даже если вы отключите компьютер от сети или контроллер домена окажется недоступным. NT обеспечивает определенную защиту кэшируемой информации. Однако если ваши задачи требуют более высокого уровня безопасности, вы можете полностью отключить кэширование, чтобы исключить попытки атак на данные в кэш-памяти. Нужно учитывать, что кэшируемые данные содержат хэш-коды других хэш-кодов паролей. Поэтому их очень сложно взломать и использовать для несанкционированного входа в систему. Мы не можем вспомнить ни одного случая использования хакерами таких данных из кэш-памяти. Чтобы отключить кэширование, установите в 0 значение параметра реестра CachedLogonsCount (типа REG_DWORD) в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon.
SAM в сети
ОС Windows NT использует протокол SMB (Server Message Block - блок серверных сообщений), разработанный совместно фирмами Microsoft, IBM и Intel. Данный протокол определяет алгоритмы функционирования файловой службы в сетевой среде. Нетрудно предположить, что во время сеанса SMB по сети должны передаваться пакеты, содержащие информацию конфиденциального характера. Среди прочего эти пакеты обычно включают в себя зашифрованные данные протокола NTLM, передаваемые NT во время фазы аутентификации.
Взломщики, используя существующие сетевые анализаторы, могут легко перехватывать данные, передаваемые по сети. Задача перехвата нужных пакетов и получения из них информации о паролях всегда считалась нелегкой. Но ситуация в корне изменилась с появлением продукта SMB Packet Capture, выпущенного компанией L0pht Heavy Industries. Это сетевой анализатор, который тесно интегрирован с программой L0phtCrack. Имея в своем распоряжении L0phtCrack, можно легко «выхватывать» из сети хэш-коды паролей, передаваемые в соответствии с протоколом SMB.
Встроенный в L0phtCrack сетевой анализатор незаметно перехватывает хэш-коды паролей и запоминает их с целью расшифровки. После расшифровки паролей злоумышленнику ничего не стоит добраться до любого сетевого ресурса, к которому имел доступ соответствующий пользователь. Вот так! Риск здесь очевидный, но и методы защиты просты.
Для защиты от подобных атак нужно использовать протокол NTLMv2, поставляемый в составе пакетов обновления SP4 и SP5, либо применять механизм создания виртуальных частных сетей (VPN - Virtual Private Network) типа Microsoft PPTP. Протокол NTLMv2 позволяет защитить данные, передаваемые по внутренней локальной сети, а PPTP обеспечивает защиту информации, передаваемой через такие «небезопасные» сети как, например, Интернет. Если вы реализуете PPTP, то обязательно установите последние сервисные пакеты, включая дополнения и исправления к ним (hotfix). Мы предупреждаем вас об этом, потому что в свое время PPTP-соединение считалось очень ненадежным. Microsoft внесла необходимые корректировки, устраняющие недостатки PPTP. Но эти корректировки будут вам недоступны, если вы не установите hotfix к пакету SP3 или более позднему.
Следует иметь в виду, что при отсутствии в вашей системе механизма VPN и технологии подписей SMB взломщик может использовать сеанс SMB для получения несанкционированного доступа в систему. Microsoft реализовала технологию подписей SMB в пакете обновления SP3 и также включила ее во все последующие пакеты обновления. При использовании подписей пакетов SMB операционная система проверяет подлинность каждого пакета, прежде чем принять его к исполнению. Однако реализация подписей SMB не всегда безопасна. Для получения более подробной информации обязательно прочитайте статью How to Enable SMB Signing in Windows NT .
Для борьбы с соответствующими средствами взлома можно запретить NT посылать в сеть хэш-коды паролей, формируемые по протоколу LAN Manager (LM). Хэш-коды LM более просты, чем коды NTLM, так как NTLM позволяет задействовать пароли, учитывающие регистр. Также NTLM допускает возможность применения дополнительных символов клавиатуры. Это расширяет диапазон символов ключа шифрования на 26. Заметим, что сложные пароли труднее поддаются расшифровке даже при наличии таких инструментов как L0phtCrack.
Целесообразно включать в пароль символ «возврат каретки», так как взломщики паролей не умеют нормально обрабатывать этот символ. Чтобы вставить «возврат каретки», нажмите клавиши Alt+0+1+3 на цифровой панели клавиатуры.
Для решения описываемой проблемы Microsoft реализовала в составе дополнений и исправлений к сервисному пакету SP3 новый ключ реестра. Он был включен во все сервисные пакеты, вышедшие после SP3. Новый параметр реестра, LMCompatibilityLevel, имеет тип REG_DWORD и размещается в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa.
При использовании NTLMv2 можно установить значение этого параметра равным 0, 1, 2, 3, 4 и 5. Если это значение равно 0, то NT при аутентификации сетевого соединения передает по сети пароли как в формате NTLM, так и в формате LM (этот метод аутентификации обеспечивает совместимость с другими системами и используется в NT по умолчанию). Если значение равно 1, то NT передает оба типа хэш-кодов только тогда, когда этого требует сервер. Если значение равно 2, то хэш-коды паролей в формате LM не используются ни при каких обстоятельствах. Если значение равно 3, применяется только аутентификация по протоколу NTLMv2. Значение параметра, равное 4, запрещает контроллеру домена использовать аутентификацию LM, а значение 5 указывает на необходимость применять при аутентификации только протокол NTLMv2. Наиболее безопасной является установка значения этого параметра равным 2. Но следует иметь в виду, что системы, поддерживающие только протокол LM (т.е. Windows 95 и Windows for Workgroups), не смогут установить соединение с данной системой NT. Полный перечень особенностей конфигурации описан в статье Microsoft How to Disable LM Authentication on Windows NT. Заметим, что при установке пакета обновления SP4 данный ключ реестра способен принимать шесть различных значений.
Еще один способ взлома системы может иметь место, если взломщик располагает возможностью физического доступа к компьютеру. Для защиты от этого метода взлома следует принять меры, препятствующие физическому доступу к компьютеру.
Можно немного расслабиться
В этой статье представлены основные идеи и особенности конфигурации, которые следует учитывать при установке и сопровождении ОС Windows NT\2000 и ее системы безопасности. Эта статья должна помочь вам несколько разгрузить свой мозг. Но не слишком расслабляйтесь. Вам по-прежнему необходимо держать систему под контролем.
Административные рекомендации:
ограничить физический доступ к серверу (станции) Windows NT. С этой целью сервер должен устанавливаться в закрытой комнате, оборудованной сигнализацией, выведенной на пульт дежурного. Комната должна быть оборудована двумя замками, либо замком с двумя разными ключами, которые никогда не должны храниться вместе. Один из ключей должен храниться у системного администратора, а другой - у сотрудника службы безопасности. Вскрываться комната должна только этими двумя сотрудниками вместе;
ограничить возможность загрузки с гибких дисков, CD-ROM. Для этого возможно либо физическое отключение накопителя на гибких дисках и CD-ROM, либо установка в BIOS загрузки только с жесткого диска и закрытие BIOS паролем супервизора с одновременным физическим отключением клавиатуры;
Желательно один из винтов на корпусе сервера оборудовать так называемым винтом «с секретом», что исключит возможность подключения стороннего жесткого диска с ОС Windows NT. При этом оптимальным способом опечатывания компьютера является заливка одного из винтов на корпусе обычным лаком для ногтей, так как на сегодня существует более 400 000 оттенков.
Комплект дискет восстановления должен находиться в сейфе, обязательно отдельно от самого сервера (то есть в другом помещении).
Установка аудита системы безопасности
1. Войдите в систему с административными правами.
2. Запустите программу User Manager. Выберите в меню: Policies, Audit и отметьте Audit These Events.
3. Выделите для аудита (по минимуму) события с успешным (Success) и неудачным (Failure) результатом выполнения; включите аудит попыток входа в систему и выхода из нее (Logon, Logoff). Закройте диалоговое окно, чтобы активизировать аудит системы.
4. Откройте программу Services в Панели Управления (Control Panel), установите для службы Планировщика NT (NT Scheduler) режим запуска от имени системы (System account). Запустите (или перезапустите) службу Планировщика.
5. Откройте командное окно DOS и проверьте текущее системное время.
6. Прибавьте к текущему времени 1-2 минуты (так, если время 11:30, используйте 11:32) и введите следующую команду:

Эта команда вставляет в список Планировщика событие, по которому в 11:32 на консоли будет запущена утилита regedt32 с правами SYSTEM.
7. Дождитесь 11:32, когда Планировщик NT запустит редактор реестра. При этом вы получите доступ ко всему реестру, включая базу данных SAM. Будьте внимательны при редактировании реестра - ошибка может вывести из строя систему.
8. Выберите HKEY_LOCAL_MACHINE, найдите дерево SAM и выделите его в левой панели экрана.
9. Выберите в меню: Security, Auditing.
10. В диалоговом окне Auditing выберите Add, Show Users.
11. Добавьте учетную запись SYSTEM, группу Domain Admins, все учетные записи пользователей, имеющих административные права, а также все остальные учетные записи, которым присвоены следующие права (User Rights):
Take ownership of files or other objects (Овладение файлами или иными объектами);
Back up files and directories (Архивирование файлов и каталогов);
Manage auditing and security log (Управление аудитом и журналом безопасности);
Restore files and directories (Восстановление файлов и каталогов);
Add workstations to domain (Добавление рабочих станций к домену);
Replace a process-level token (Замена маркера уровня процесса).
12. Отметьте Audit Permission on Existing Subkeys.
13. Отметьте Success и Failure для следующих полей:
Query Value;
Set Value;
Write DAC;
Read Control.
14. Нажмите кнопки OK, Yes.
15. Повторите шаги с 10 по 14 для ключа SECURITY, если это необходимо. Это не требуется, если вам нужно активизировать аудит только тех ключей, которые содержат пароли.
16. Выйдите из редактора реестра.
Остановите службу Планировщика и измените его конфигурацию так, чтобы он работал от имени пользователя, которое употреблялось ранее (до шага 4). Если вы не применяете в обычной работе системы Планировщик NT, то просто остановите его или, еще лучше, заблокируйте (вариант disabled).

Вопросы локальной безопасности систем под управлением ОС типа Windows NT/2000/XP
Прежде всего, определимся с термином "локальный доступ". Под этим термином понимается физический доступ к компьютеру, т.е. возможность его включения/выключения, загрузки операционной системы, доступ к накопителям (HDD, FDD, CD-ROM и т.д.).
Мало кто задумывается о том, что может произойти, если покинуть свое рабочее место всего на 5-10 минут. За это время, даже если компьютер выключен и вход в операционную систему защищен комбинацией логин/пароль, с помощью специальных средств возможно получение полного доступа ко всем данным, хранящимся на жестком диске, а также получение доступа к другим машинам, если компьютер подключен к локальной сети. Если за компьютером работают несколько пользователей, то локальной политикой безопасности, доступной в операционных системах (ОС) семейства NT, возможно ограничение доступа к вашим документам, однако права администратора позволяют получить полный доступ (чтение/запись/удаление) к абсолютно всем данным системы, чем и может воспользоваться злоумышленник.
Почему для анализа была выбрана группа операционных систем Windows NT/2000/XP? Семейство операционных систем Windows NT/2000/XP (далее - просто Windows NT) на сегодняшний день наиболее распространено, т.к. имеет широкие возможности работы с конфигурацией операционной среды, поддерживает устаревшее программное обеспечение для операционных систем DOS и предыдущих версий Windows (особенно хорошо это реализовано в Windows XP).
Итак, рассмотрим подробно, какие недостатки имеются в системе безопасности и какие действия нужно предпринять, чтобы максимально усложнить несанкционированный доступ к данным на жестком диске.
Система безопасности NT работает только при загруженной операционной системе, следовательно, первым и самым простым способом будет являться загрузка с внешнего носителя (дискета или CD-ROM) и получение полного доступа к файловой системе на жестком диске, которые затем переносятся на дискету или другой съемный накопитель (например, ZIP-drive). Как известно, в семействе операционных систем Windows NT реализована возможность контроля за локальным доступом (т.е. доступом к локальному жесткому диску). Реализуется эта возможность с помощью новой (по сравнению с FAT) файловой системы NTFS. Таким образом, Windows NT поддерживает обе эти файловые системы, и если использовать для загрузки загрузочную дискету Windows 98, и загрузиться с нее в MS-DOS, то при наличии NTFS доступа к данным на жестком диске не будет. Это, тем не менее, исправляется при использовании программы NTFSDOS.ЕХЕ (автор - Mark Russmovich), которая позволяет в MS-DOS получить доступ к разделам с NTFS.
Далее можно перенести необходимые данные на внешний носитель, либо скопировать файл SAM. Файл SAM (Security Account Manager) хранит хэши (hash) паролей (пароли, зашифрованные хэш-функцией, а при использовании дополнительной утилиты шифрования Syskey - хэши хэшей паролей) для учетных записей пользователей. Сам файл SAM располагается в каталоге Win_dir\SYSTEM32\CONFIG\. Когда Windows NT запущена и работает, доступ к файлу SAM заблокирован системой. Скопировав файл SAM на дискету, можно расшифровать его с помощью программ типа L0phtCrack 3.0, получив тем самым все логины и пароли (в т.ч. и администратора). Хэш-функция необратима, т.е. для того, чтобы найти пароль, надо перебрать все возможные значения либо по словарю, либо прямым перебором (brute force). С увеличением мощностей современных компьютеров и используя возможность распределенной работы (на нескольких машинах) перебор не займет много времени, если пароль недостаточно сложный.
Также в Internet можно найти операционную систему Syslinux, которая помещается на дискету, производится загрузка с этой дискеты, вследствие чего появляется возможность работы с файловой системой NTFS, обращаться к SCSI-устройствам (что невозможно при использовании MS-DOS, загруженной с загрузочной дискеты Windows 98), производить изменения в реестре Windows NT и назначать новые пароли для всех учетных записей, в т.ч. и для администратора, корректируя файл SAM.
Единственный недостаток Syslinux (с точки зрения злоумышленника, который хочет получить несанкционированный доступ) - это некорректная работа с кириллицей. Это также исправимо, так как войдя в Windows NT даже под учетной записью гостя, возможен запуск MMC (Microsoft Management Console) и просмотр логинов всех пользователей. Допустим, логин для встроенной учетной записи администратора (по умолчанию Administrator для нелокализованной версии ОС и Администратор для локализованной) может быть переименован в Админ. Теперь необходимо посмотреть с помощью ММС этот новый логин, перезагрузиться в Syslinux и, идентифицируя встроенную учетную запись администратора в файле SAM по ID=500, изменить пароль. Теперь возможен вход в систему под новой учетной записью администратора.
Что можно посоветовать для того, чтобы затруднить эти действия? Подчеркиваю, именно ЗАТРУДНИТЬ, а не полностью предотвратить, так как последнее невозможно в принципе, и сейчас будет ясно, почему.
Итак, прежде всего, поставить в BIOS SETUP пароль на вход/изменение BIOS и (важно!), на вход в систему. Это делается так (на примере Award Modular BIOS v. 4.51G): USER PASSWORD, SUPERVISOR PASSWORD - задаем пароль, причем желательно одинаковый, чтобы потом не путаться. Ставить различные пароли имеет смысл, если на компьютере работают несколько пользователей, тогда SUPERVISOR PASSWORD должен знать только администратор, а остальные - только USER PASSWORD. BIOS FEATURES SETUP -> Boot sequence -> C only, BIOS FEATURES SETUP -> Security option -> System. Теперь при входе в систему будет запрашиваться пароль (Enter password) и загрузка с дискеты будет невозможна. Конечно, и это можно обойти, переставив джампер на материнской плате для сброса параметров BIOS по умолчанию, но вряд ли кто-то будет развинчивать ваш системный блок. Также сброс пароля можно осуществить, сбросив установки BIOS по умолчанию программным способом (тестировалось на Award Modular BIOS v. 4.51G под MS-DOS и Windows 98): создается файл типа С:\kill.txt, который содержит три строки:
о 70 71
о 71 17
q
а затем выполняется команда debug <C:\kill.txt. Данная команда разрушает контрольную сумму CMOS. Дело в том что, определенный диапазон адресов CMOS защищен контрольной суммой, при нарушении которой загружаются установки по умолчанию, в т.ч. и сбрасывается пароль. При перезагрузке будет выведено сообщение: CMOS checksum error - defaults loaded. Press DEL to enter Setup. Далее можно войти в Setup BIOS и разрешить загрузку с дискеты. На других версиях BIOS все делается аналогично с учетом специфики - другие названия меню, принцип изменения порядка загрузки и т.д.
Единственный выход в данной ситуации - применение специальных аппаратных или программных средств шифрования, о которых будет сказано ниже.
Следующим аспектом безопасности является собственно предотвращение несанк-ционированных действий непосредственно в операционной системе. Как указывалось выше, линейка Windows NT предоставляет огромные возможности по настройке локальной безопасности. Для каждого пользователя может быть ограничен доступ к определенным файлам, папкам, предоставлена возможность запускать только определенные приложения и т.д. Таким образом, можно рекомендовать следующее:
- удалить встроенную учетную запись Гость (Guest), оставив только учетные записи пользователей, работающих на данном компьютере. Дело в том, что исследователь Radim "EliCZ" Picha обнаружил серьезную уязвимость в безопасности Windows NT и Windows 2000. Им была написана программа (exploit), демонстрирующая очевидную слабость локальной подсистемы безопасности NT/2000 и полностью компрометирующая всю систему безопасности этих операционных систем. Программа, названая DebPloit (от английских слов Debug и Exploit), использует уязвимость в подсистеме отладки (debugging subsystem) и позволяет ЛЮБОМУ пользователю с ЛЮБЫМИ привилегиями (даже пользователям, входящим в группы Guests и Restricted Users), выполнять программный код с правами администратора. Запустив эксплоит, злоумышленник запускает уже упомянутую ММС, которая запустится с правами администратора и добавляет нового пользователя (естественно, с правами администратора), а затем заново входит в систему, используя созданную учетную запись. Теперь он обладает правами администратора со всеми вытекающими последствиями. В Windows XP эта уязвимость устранена.
- Необходимо поставить все существующие для ОС сервиспаки. Например, сервиспак SP3 для Windows 2000 исправляет уязвимость, которую использует DebPloit.
- Все пользователи должны иметь пароли, устойчивые к прямому перебору, т.е. содержать буквенные, цифровые и специальные символы в разных регистрах и иметь длину не менее 10 символов. Таким образом, пароль типа Nb6$iL78@+&67K будет подбираться прямым перебором несколько лет. И уж тем более, пароль не должен нести смысловую нагрузку, как, например: quake, doom, password и т.д.
- Учитывать социальный фактор: не записывать пароль на бумажках, не сообщать пароль кому-либо, игнорировать письма от якобы системного администратора сообщить логин и пароль и т.д.
- Пользователи, не имеющие прав администратора, не должны иметь доступ к системным файлам, реестру и т.д. Например, файл MSV_0.dll, отвечающий за проверку подлинности пароля при локальном входе в систему, может быть скопирован и изменен таким образом, что любой пароль для любого пользователя будет считаться верным.
- Постоянно контролировать процессы, запущенные в системе. Администратору, разумеется, необходимо знать каждый процесс и для чего он запускается. Допустим, постановка программы-кейлоггера (отслеживает нажатия клавиш и записывает их в файл) часто не требует для установки прав администратора, а между тем анализ лог-файла за месяц наверняка позволит узнать пароли и логины всех пользователей.
- Поставить на компьютер последнюю версию хорошего антивируса (AVP, DrWEB, ...) и регулярно обновлять антивирусные базы. Также необходимо политикой безопасности запретить всем пользователям, кроме администратора, отключать антивирус.
- В отдельных случаях может быть оправдано применение специальных систем шифрования: SeNTry2020, Security Plus, Cryptext, Верба-OW. Однако эти системы, особенно те, которые сертифицированы ФАПСИ, весьма дорогостоящи и сложны в обслуживании для простого пользователя и поэтому редко применяются в обычных фирмах и на предприятиях.
- Для шифрования особо важных папок и файлов может применяться программа Kremlin Encrypt. Применение весьма стойких разнообразных алгоритмов шифрования (BlowFish, CAST-128, RC4, IDEA, NewDES, Safer SK-128) в комплексе со сложным паролем сделает ваши данные неприступными.
Данная статья ни в коей мере не претендует на абсолютную полноту и объективность, рассмотрены лишь основы локальной безопасности систем под управлением ОС типа WinNT/2000/XP. Сетевая же безопасность является отдельной темой для обсуждения, так как количество известных сетевых уязвимостей на порядок больше локальных.

Списки контроля доступа
Теория
Любая серьезная многопользовательская ОС предусматривает разграничение доступа к объектам для пользователей и их группам. Под объектом здесь подразумевается не только объект в каноническом его значении (т.е. что-то закрытое, самодостаточное), но и любой разделяемый ресурс. Скажем, этим ресурсом может быть файл, именованный канал, синхронизирующая структура ядра ОС, процесс, поток, служба и т.д. (не будем углубляться в дебри системного программирования). Для Windows NT все разделяемые, защищаемые и именованные структуры являются истинными объектами, т.е. содержат, кроме самих данных, и код по их обработке — методы, чем достигается независимость внутренней реализации объекта от внешнего интерфейса. Это позволяет также легко вести учет ссылок на конкретный экземпляр объекта. К слову, ряд структур, используемых только отдельными компонентами ядра, объектами не являются, так как они не должны соответствовать приведенным выше требованиям.
Итак, мы знаем, что у нас есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, значит, это "свой", впускаем, нет — "пшел вон!" Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя (здесь идет серьезное обобщение, впрочем, для нас это не важно), создающий рабочую среду (оболочку и т.д.). Этот процесс получает контекст защиты (так называемый маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы (т.е. открытые программы) запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.
Однако остается еще одна проблема: при обращении программы (процесса) к объекту ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы "остальные", которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (и NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту — уже упомянутый список контроля доступа. Что же это такое, и чем оно отличается (в положительную сторону) от других методов защиты?
Собственно, разительных отличий нет. И там, и там что-то с чем-то сверяется (этим озабочена та часть ядра, которая отвечает за безопасность — справочный монитор безопасности для NT), а потом выдается либо разрешение на доступ, либо запрет. Однако достоинство списков контроля (управления) доступа (Access Control List, ACL) в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности (научился использовать их для файлов, разберешься и для всего остального).
Рассмотрим теперь, что представляет собой дескриптор защиты. Если не углубляться в подробности, то он состоит из следующих основных компонентов:

Номер версии защиты.
Флаги (необязательно).
SID владельца.
SID группы.
Список управления избирательным доступом (Discretionary Access Control List, DACL).
Системный список управления доступом (System Access Control List, SACL).

Теперь поясним, что каждый элемент означает. Итак, с номером защиты и с флагами, думаю, все понятно; нам они, собственно, и неинтересны. А что такое SID владельца? Дело в том, что все объекты, выполняющие в системе какие-нибудь действия (например, пользователи и группы), кроме имени, имеют свой идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект (вспомните содержимое папки RECYCLER, названия вложенных папок — идентификаторы защиты пользователя), что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины, формирующееся по правилам, нас здесь не касающимся:-). В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). С SID группы аналогично — это идентификатор основной группы владельца (используется только подсистемой POSIX).
А теперь самое вкусное: DACL и SACL. По сути дела, это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).
ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо листьями. Контейнеры могут содержать другие контейнеры и/или листья и так далее. ACE бывают двух общих видов (особенности Active Directory не рассматриваем): "доступ разрешен" и "доступ отклонен" (позже я это докажу вам на примере). Причем сначала идут запрещающие ACE, а потом разрешающие (это очень важно: в обратном случае редактор DACL файловой системы, например, сочтет это ошибкой и предложит вам унаследовать DACL родителя, хотя это случается архиредко и связано с использованием устаревших функций Win32).
SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как "успех", так и "отказ". В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.
Алгоритмы
От общей теории перейдем к рассмотрению алгоритмов работы ACL:

Если DACL не существует (null), то все имеют полный доступ (именно с этой точки зрения можно смотреть на FAT).
Если DACL пустой, то никто не имеет доступа.
Если вызываемый процесс (точнее, поток, но это нам не важно) имеет право на захват объекта во владение, то он может стать владельцем объекта и изменить DACL.
Если вызываемый процесс является владельцем, то он может изменить DACL.
Из маски прав доступа удаляется маска доступа каждого ACE типа "доступ отклонен", если SID совпадает с SID маркера доступа процесса.
К полученной маске прав доступа добавляется маска доступа каждого ACE типа "доступ разрешен", если SID совпадает с SID маркера доступа процесса (не считая тех прав, в которых уже отказано).
Полученная маска доступа и определяет права доступа, которые имеет программа, их запрашивающая (точнее, пользователь, ее запустивший — SID-то его).

Это общая схема, тем не менее, дающая нам возможность понять, как все это работает. Теперь подобьем наши знания и добавим новые:

Владелец объекта (по умолчанию его создатель) способен делать с ним все что угодно, так как может изменить DACL (да и SACL тоже).
Пользователь, который имеет права на вступление во владение (администратор, например), способен стать его владельцем со всеми вытекающими...
Если права для пользователя или группы не указаны, то они не имеют доступа к объекту.
Права имеют кумулятивный характер, т.е. наследуются пользователями конкретной группы. Если, скажем, группа Все имеет полный доступ к какому-либо объекту, то и все члены этой группы тоже имеют полный доступ.
Запрет имеет большие привилегии, чем разрешение. Кажется, зачем это надо, ведь можно просто не указать разрешение? А если мне нужно, чтобы конкретный пользователь группы не имел доступа к объекту, а вся группа имела? Не удалять же его из группы:-)!
По умолчанию созданный (или скопированный) объект наследует права доступа (DACL, а также SACL) от родительского контейнера, но это можно изменить. При наследовании ACE удалить невозможно, но можно добавить.
При необходимости можно распространить DACL (и SACL) на все вложенные контейнеры и объекты, тем самым заменив их права.

Будем помнить эти несложные правила. Что ж, я, наверное, утомил читателя пространными рассуждениями о принципах строения и работы ACL. Перейдем к более интересной и полезной практической работе. Перед этим, однако, я настаиваю на том, чтобы вы еще раз прочитали раздел Алгоритмы — это основополагающие сведения.
Практика
Как и говорилось, экспериментировать мы будем над ФС и реестром (в систему встроен графический редактор ACL и консольная версия редактора DACL — cacls.exe). В первую очередь, потому, что это актуально для пользователя, а во вторую — что здесь применяются все возможности ACL (включая наследование). В качестве ОС выбрана русская версия Windows XP Professional. Для начала в Windows XP необходимо отключить опцию Использовать простой общий доступ к файлам из закладки Вид окна Свойства папки Панели управления. Данный режим предназначен для неподготовленных пользователей и весьма ограничен в возможностях. В Windows XP Home Edition вам это сделать не удастся, поэтому нужно будет либо работать в Безопасном режиме (Safe Mode), либо воспользоваться консольной утилитой cacls.exe (или ее расширенным аналогом из Support Tools — xcacls.exe).
Итак, сначала откроем редактор ACL. Для файловой системы достаточно в Проводнике в контекстном меню выбрать пункт Свойства, а затем закладку Безопасность (для папок можно сразу выбрать пункт Общий доступ и безопасность...). Для реестра выбираем нужную ветвь (разграничение доступа идет только на ветви, а не отдельные ключи) и в контекстном меню выбираем пункт Разрешения... (для пользователей Windows NT и 2000 придется воспользоваться программой regedt32.exe, так как только она обладает нужной функциональностью). Так как в обоих случаях используется один и тот же редактор ACL и общие принципы, то продолжать я буду на примере свойств папки.
На нем перечислены пользователи и их права. Можно добавлять новых и удалять уже имеющихся (если позволяет наследование). Однако это лишь вершина айсберга — здесь перечислены только общие типы доступа, основанные на нескольких ACE с одинаковым SID. Проверим? Жмем кнопку Дополнительно и оказываемся в настоящем редакторе ACL.
Как видим, тут перечислены все ACE, причем сначала идут запрещающие. Мы можем добавить, удалить и изменить ACE. При добавлении нас спросят об имени пользователя, которое можно ввести вручную либо воспользоваться поиском, нажав в появившемся окне Дополнительно, Поиск. Кнопка Типы объектов позволяет указать, что мы ищем: пользователей, группы или встроенных пользователей/группы. Кстати, имя имеет вид Имя контейнера (компьютера в нашем случае)\Имя пользователя, хотя можно просто вводить имя пользователя. С удалением все понятно, а редактирование представляет некоторый интерес.
Мы вправе менять такие параметры, как имя пользователя (т.е. выбрали редактировать одно, а потом взяли да и сменили), параметры наследования (вложенные папки, объекты и т.д.), ограничение наследования (галочка внизу, становится доступна, когда выбрано наследование для подпапок и файлов) и собственно сами права. Кнопка Очистить выполняет быструю очистку всех галочек в ACE. Если мы поставим сразу запрещающие и разрешающие галочки, то будет создано два ACE: запрещающее и разрешающее (помните о примере). Причем этого можно добиться также и в самом первом окне (до нажатия кнопки Дополнительно) редактированием базовых типов доступа. Думаю, с этим разобрались.
В расширенный редакторе ACL внизу можно заметить две галочки, отвечающие за наследование. Первая указывает на то, что данный объект наследует права доступа от родительского. Если снять эту галочку, то нам предложат либо скопировать унаследованные права в качестве заданных явно (что в большинстве случаев удобно), либо просто очистить ACL, если нет других ACE, кроме унаследованных. Вторая галочка позволяет заменить разрешения всех объектов и контейнеров заданными здесь, то есть по сути дела заставляет их наследовать права.
Что касается аудита — все абсолютно аналогично рассмотренному DACL включая наследование.
Перейдем к владению (закладка Владелец). По умолчанию владельцем является его создатель, т.е. пользователь либо группа. Однако можно вступить во владение объектом, если вы обладаете таким правом (по умолчанию им обладают члены группы Администраторы) либо если в DACL явно указано, что вы можете изменить владельца. Мы просто выбираем доступного пользователя или группу для владения, если надо, ставим галочку Заменить владельца субконтейнеров и объектов и жмем Применить. Все, объект наш:-).
Ну и напоследок бросим взгляд на закладку Действующие разрешения. Это полезное нововведение XP, позволяющее не просчитывать в уме права конкретного пользователя/группы. Достаточно выбрать имя, и мы получим список прав на основе имеющихся ACE.Остается добавить, что внешний вид редактора ACL зависит от объекта, разрешения которого мы редактируем, т.е. могут быть недоступны какие-то опции. Если вам интересно, можете поэкспериментировать с консольными утилитами cacls.exe и xcacls.exe. Первая — аналог простого редактора базовых типов доступа, вторая позволяет работать с разрешениями более точно. Не забывайте, что, перетаскивая объект в другую папку в Проводнике, мы тем самым заставляем его унаследовать права этой папки. Чтобы этого не произошло, необходимо пользоваться консольными утилитами с соответствующими ключами либо файл-менеджерами, поддерживающими эту опцию (Total Commander, например).

Настройка системы безопасности Windows XP
Операционная система WinXP обладает развитой системой безопасности, которая, тем не менее, нуждается в настройке ¹⁰. Мы надеемся, что вы понимаете, что система WinXP должна устанавливаться на разделах NTFS, что применение файловой системы FAT32 не рекомендуется, исходя из принципов безопасности (встроенные средства безопасности просто не могут быть реализованы при условии применения FAT32). В случае применения файловой системы FAT 32 почти все утверждения данного раздела теряют для вас всякое значение. Единственный способ включить все разрешения файловой системы - преобразовать диск в формат NTFS.
После чистой установки WinXP предлагаемые по умолчанию параметры безопасности работают как переключатели типа "включить-выключить". Такой интерфейс носит по умолчанию название Простой общий доступ (Simple File Sharing).Такая конфигурация обладает низким уровнем безопасности, практически совпадающей со стандартной конфигурацией Win95/98/Me.
Если вас не устраивает такая конфигурация, вы можете воспользоваться всей мощью разрешений для файлов в стиле Win2K. Для этого откройте произвольную папку в Проводнике и выберите Сервис " Свойства папки (Tools " Folder options). Перейдите на вкладку Вид найдите в списке флажок Использовать простой общий доступ к файлам (рекомендуется) (Use File Sharing (recommended) и снимите его. ¹¹
Когда вы выключаете простой общий доступ, в диалоговом окне свойств любой папки появляется вкладка Безопасность.
Аналогично осуществляется выдача разрешений на файлы. Все разрешения хранятся в списках управления доступом (Access Control List - ACL).
При установке и удалении разрешений руководствуйтесь следующими основными принципами:

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

Установка разрешения из командной строки

Утилита командной строки cacls.exe доступна в WinXPPro позволяет просматривать и изменять разрешения файлов и папок. Cacls - сокращение от Control ACLs - управление списками управления доступом.Ключи командной строки утилиты cacls
Таблица 1

Ключ	Действие
/T	Смена разрешений доступа к указанным файлам в текущей папке и всех подпапках
/E	Изменение списка управления доступом (а не полная его замена)
/C	Продолжить при возникновении ошибки "отказано в доступе"
/G пользователь:разрешение	Выделение пользователю указанного разрешения. Без ключа /E полностью заменяет текущие разрешения
/R пользователь	Отменяет права доступа для текущего пользователя (используется только с ключом /E)
/P пользователь:разрешение	Замена указанных разрешений пользователя
/D пользователь	Запрещает пользователю доступ к объекту

С ключами /G и /P нужно использовать одну их перечисленных ниже букв (вместо слова разрешение):

F (полный доступ) - эквивалентно установке флажка Разрешить полный доступ (Full Control) на вкладке Безопасность.
C (изменить) - тождественно установке флажка Разрешить Изменить (Modify)
R (чтение) - эквивалентно установке флажка Разрешить Чтение и выполнение (Read & Execute)
W (запись) - равнозначно установке флажка Разрешить запись (Write)

WinXP позволяет предотвратить попадание конфиденциальных данных в чужие руки. Шифрующая файловая система (Encrypting File System - EFS) шифрует файлы на диске. Однако, слудует иметь ввиду, что если вы утеряете ключ для расшифровки, данные можно считать утерянными. Поэтому если вы решите воспользоваться преимуществанми EFS необходимо создать учетную запись агента восстановления, резервную копию собственного сертификата и сертификата агента восстановления.
Если вы предпочитаете работать с командной строкой, то можете воспользоваться программой cipher.exe.Команда cipher без параметров выводит информацию о текущей папке и размещенных в ней файлах (зашифрованы они или нет). В таблице 2 приведен список наиболее часто используемых ключей команды cipher
Таблица 2

Ключ	Описание
/E	Шифрование указанных папок
/D	Расшифровка указанных папок
/S:папка	Операция применяется к папке и всем вложенным подпапкам (но не файлам)
/A	Операция применяется к указанным файлам и файлам в указанных папках
/K	Создание нового ключа шифрования для пользователя, запустившего программу. Если этот ключ задан, все остальные игнорируются
/R	Создание ключа и сертификата агента восстановления файлов. Ключ и сертификат помещаются в файл .CFX, а копия сертификата в файле .CER
/U	Обновление ключа шифрования пользователя или агента восстановления для всех файлов на всех локальных дисках
/U /N	Вывод списка всех зашифрованных файлов на локальных дисках без каких-либо других действий

Устранение проблем с разрешениями

Агент восстановления данных

Агентом восстановления данных (Data Recovery Agent) назназначается обычно администратор. Для создания агента восстановления нужно сначала сохдать сертификат восстановления данных, а затем назначить одного из пользователей таким агентом.
Чтобы создать сертификат нужно сделать следующее:

Нужно войти в систему под именем Администратор
Ввести в командной строке cipher /R: имя файла
Введите пароль для вновь создаваемых файлов

Файлы сертификата имеют расширение .PFX и .CER и указанное вами имя.
ВНИМАНИЕ эти файлы позволяют любому пользователю системы стать агентом восстановления. Обязательно скопируйте их на дискету и храните в защищенном месте. После копирования удалите файлы сертификата с жесткого диска.
Для назначения агента восстановления:

Войти в систему под учетной записью, которая должна стать агентом восстановления данных
В консоли Сертификаты перейдите в раздел Сертификаты - Текущий пользователь " Личные (Current User " Personal)
Действие " Все задачи " Импорт (Actions " All Tasks " Import) для запуска мастера импорта сертификатов
Проведите импорт сертификата восстановления

При неправильном использования средств шифрования вы можете получить больше вреда, чем пользы.
Краткие рекомендации по шифрованию:

Зашифруйте все папки, в которых вы храните документы
Зашифруйте папки %Temp% и %Tmp%. Это обеспечит шифрование всех временных файлов
Всегда включайте шифрование для папок, а не для файлов. Тогда шифруются и все создаваемые в ней впоследствии файлы, что оказывается важным при работе с программами, создающими свои копии файлов при редактировании, а затем перезаписывающими копии поверх оригинала
Экспортируйте и защитите личные ключи учетной записи агента восстановления, после чего удалите их с компьютера
Экспортируйте личные сертификаты шифрования всех учетных записей
Не удаляйте сертификаты восстановления при смене политик агентов восстановления. Храните их до тех пор, пока не будете уверены, что все файлы, защищенные с учетом этих сертификатов, не будут обновлены.
При печати не создавайте временных файлов или зашифруйте папку, в которой они будут создаваться
Защитите файл подкачки. Он должен автоматически удаляться при выходе из Windows

Конструктор шаблонов безопасности
Шаблоны безопасности являются обыкновенными ASCII - файлами, поэтому теоретически их можно создавать с помощью обыкновенного текстового редактора. Однако лучше воспользоваться оснасткой Security Templates консоли Microsoft Management Console (MMC). Для этого в командной строке нужно ввести mmc /a в этой консоли выбрать меню File - Add/Remove. В диалоговом окне Add Standalone Snap-in выбрать Security Templates - Add.
Управление оснасткой
Шаблоны безопасности расположены в папке \%systemroot%\security\templates. Количество встроенных шаблонов изменяется в зависимости от версии операционной системы и установленных пакетов обновлений.
Если раскрыть любую папку в Security Templates, то в правой панели будут показаны папки, которые соответствуют контролируемым элементам:

Account Policies - управление паролями, блокировками и политиками Kerberos
Local Policies - управление параметрами аудита, пользовательскими правами и настройками безопасности
Event Log - управление параметрами системного журнала
Restricted Groups - определение элементов различных локальных групп
System Services - включение и отключение служб и присвоение права модификации системных служб
Registry - назначение разрешений на изменение и просмотр разделов реестра
File System - управление разрешениями NTFS для папок и файлов

Все о журнале безопасности Windows 2000 Информация о программах, запускавшихся взломщиком, нередко помогает восстановить полную картину действий постороннего лица, проникшего в сеть. Другими свидетельствами могут служить изменения полномочий и политик или несанкционированная перезагрузка системы.
Контролировать выполнение программ можно с помощью категории Audit process tracking (аудит запуска процесса) Windows 2000. Могут пригодиться и категории аудита действий операционной системы Audit privilege use (аудит использования привилегий), Audit policy change (аудит изменения политики) и Audit system events (аудит системных событий). Наряду с другими категориями аудита, представленными в данной серии статей о журнале безопасности Windows 2000, эти события помогут понять, какие действия предпринимал взломщик, пытавшийся нарушить целостность сети.
Audit process tracking
Audit process tracking не отслеживает неудачных событий, но когда категория настроена на контроль успешных действий, то фиксируются два события: с ID 592 (создан новый процесс) и с ID 593 (процесс завершен). Категория Audit process tracking указана как Detailed tracking в списке Category оснастки Event Viewer консоли Microsoft Management Console (MMC).
Когда пользователь запускает исполняемый файл, такой, как Microsoft Excel, Windows 2000 регистрирует событие с ID 592. Данное событие указывает, какая программа была запущена и когда. Пример сообщения о событии показан на Экране 1; поля Time, User и Image File Name указывают, что пользователь Билл запустил Excel в 5 ч 51 мин пополудни. Следует обратить внимание, что Windows 2000 регистрирует полный путь к выполняемому файлу, в отличие от NT, регистрирующей только имя файла.
Поле Logon ID соответствует ID регистрации, который был назначен Биллу при входе в систему. Данный идентификатор позволяет связать событие создания процесса с событием успешной регистрации с ID 528.
Начиная новый процесс, Windows 2000 присваивает ему уникальный номер, Process ID. Этот номер показан в поле New Process ID события с ID 592. Обычно следующим действием после запуска приложения является открытие пользователем данной программы какого-либо файла. В статье «Аудит доступа к объектам» (опубликованной в предыдущем номере — прим. ред.) я отмечал, что в описании события с ID 560 также имеется поле Process ID, которое можно использовать для идентификации связанных событий с ID 560 и ID 592. Однако в событии с ID 592 Windows 2000 регистрирует иной ID процесса, нежели в событии с ID 560 или любом другом. Событие с ID 592 отображает ID процесса как десятизначное число, тогда как другие события (и закладка Processes диалогового окна Task Manager) показывают ID процесса как трех- или четырехзначное число. По некоторым сведениям, разработчики Microsoft устранили это противоречие в операционных системах Windows 2002 и Windows XP.
Для идентификации процесса, запустившего новый процесс, можно воспользоваться полем Creator Process ID события с ID 592. Достаточно отыскать предыдущее событие с ID 592 с идентификатором Process ID, совпадающим с полем Creator Process ID избранного события. Оба поля события с ID 592 имеют десятизначный формат.
В программе Event Viewer нет фильтра для сортировки событий журнала безопасности по ID регистрации или ID процесса, но можно отыскивать события с конкретным ID. Чтобы найти события, содержащие определенные ID, следует открыть оснастку Event Viewer, щелкнуть правой кнопкой мыши на журнале Security и выбрать пункты View, Find. Затем нужно ввести идентификатор в поле Description и щелкнуть на кнопке Find Next.
Когда пользователь закрывает приложение, Windows 2000 регистрирует событие с ID 593. Событие с ID 593 располагает полем Process ID, но, как указано выше, этот идентификатор не совпадает с ID процесса соответствующего события 592, зарегистрированного операционной системой, когда пользователь открыл прикладную программу.
Наряду с решением проблемы соответствия Process ID, пользователям предстоит связать события образования процессов, доступа к объектам и регистрации — с документом, учитывая необходимость проверки времени, когда пользователь зарегистрировался; приложения, открытого пользователем; файлов и других объектов, к которым пользователь обращался из каждого приложения. Найти связь между событиями нетрудно при работе на автономном компьютере, где пользователь регистрируется, запускает приложения и обращается к файлам только на одной системе. Но в реальной сети задача не столь проста. Windows 2000 регистрирует события образования процессов на компьютере, выполняющем программу (на локальной станции пользователя), а события доступа к объектам регистрируются на компьютере, на котором хранится объект. Например, если пользователь через сеть открывает файл на файл-сервере FS1, то служба Server открывает файл на FS1 от имени пользователя. Поэтому невозможно напрямую идентифицировать приложения, с помощью которых пользователь открыл файлы, хранящиеся на удаленном файл-сервере.
Например, пользователь регистрируется на рабочей станции, запускает Excel и редактирует электронную таблицу, расположенную на файл-сервере. Windows 2000 регистрирует событие с ID 592 в журнале безопасности рабочей станции, а событие с ID 560 — в журнале безопасности сервера. Идентификаторы процессов этих двух событий не совпадают (и не совпали бы, даже если бы Windows 2000 использовала один и тот же ID процесса для обоих событий). Необходимо отыскать событие с ID 592 в журнале безопасности рабочей станции, соответствующее событию с ID 560 в журнале безопасности сервера.
Активизация на сервере категории Audit process tracking не поможет получить дополнительные сведения о приложениях, выполняемых на рабочей станции пользователя. Однако благодаря событиям этой категории можно следит за использованием серверных программ, таких, как Microsoft SQL Server и Microsoft Exchange Server, и любых программ, исполняемых администраторами и операторами при локальной регистрации на сервере. Активизация данной категории создает нагрузку на ресурсы сервера, поэтому необходимо внимательно следить за ее влиянием на производительность.
Отслеживание процедур регистрации и использования процессов и объектов поможет контролировать действия вероятного взломщика. А наблюдая за попытками использования полномочий, можно вовремя заметить подозрительные действия. Подобные действия помогает обнаружить категория Audit privilege use.
Audit privilege use
Категория Audit privilege use отслеживает успешные и неудачные попытки использования полномочий, предоставленных пользователю (в статьях и документации Microsoft не выработано единой терминологии, и термины privileges и rights используются как равнозначные). Существует более 34 полномочий: от мощных, таких, как Act as part of the operating system (работать как часть операционной системы), до довольно безобидных прав, как Bypass traverse checking (обойти перекрестную проверку). После активизации категории Audit privilege use в журнале безопасности начинают регистрироваться три события: с ID 577 (вызов привилегированной службы), ID 578 (привилегированная операция с объектом) и ID 576 (специальная привилегия, предоставленная новой учетной записи).
Когда пользователь пытается применить полномочия, Windows 2000 регистрирует событие с ID 577 или ID 578, в зависимости от типа полномочий (Windows 2000 контролирует одни полномочия по службам, а другие — по объектам). В обоих случаях в поле Privileges указывается использованное полномочие. Windows 2000 регистрирует краткое имя полномочия, которое всегда начинается с Se и заканчивается на Privilege. Но эти краткие имена нельзя увидеть, оперируя полномочиями в оснастке MMC Group Policy Editor (GPE). Вместо них приводятся полные описания полномочий. Например, на Экране 2 показано событие с ID 577, зарегистрированное операционной системой, когда я перевел часы компьютера. Полномочие SeSystemtimePrivilege соответствует полномочию Change the system time в редакторе GPE.
Если пользователю разрешено применять полномочия, то операционная система регистрирует успешное событие с ID 577 или событие ID 578. Если пользователь пытается выполнить действие, не имея соответствующих прав, то Windows 2000 регистрирует неудачное событие. Для некоторых полномочий поля Primary User Name и Primary Domain Name идентифицируют пользователя, вызвавшего событие. Однако для полномочий, которые использует серверный процесс, эти поля соответствуют учетной записи данного компьютера. Отличительный признак таких полномочий — совпадение поля Primary User Name с полем Computer со знаком «$» в конце.
В таких случаях определить пользователя, применившего полномочие, можно по данным полей Client User Name и Client Domain. Поля Primary Logon ID и Client Logon ID соответствуют полю Logon ID события с ID 528 или ID 540, зафиксированного операционной системой при регистрации пользователя.
Поле Process ID события с ID 578 идентифицирует процесс, непосредственно вызвавший событие. Например, при просмотре журнала безопасности процесс Services от имени администратора использует полномочие Se-SecurityPrivilege (т. е. Manage auditing and security log). Соответствующий идентификатор процесса в событии с ID 578 принадлежит процессу Services.
Категория Audit logon events содержит специальные идентификаторы событий для действий при регистрации пользователей, поэтому по умолчанию Windows 2000 не записывает успешные и неудачные попытки применения полномочий на регистрацию. Эти полномочия — за исключением Access this computer from the network и Deny access to this computer from the network — начинаются словами Logon as или Deny logon. Windows 2000 также не заносит в журнал информацию о некоторых других полномочиях — например, SeBackupPrivilege (резервное копирование файлов и каталогов) и SeRestorePrivilege (восстановление файлов и каталогов), — вызываемых так часто, что они быстро переполнили бы журнал безопасности. Чтобы система выполняла аудит использования этих полномочий, следует изменить параметр реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa: Set the FullPri-vilegeAuditing, имеющий тип REG_DWORD, и присвоить ему значение 1.
Windows 2000 никогда не регистрирует использование полномочий SeAudit-Privilege (Generate security audits — генерировать проверку безопасности), SeCreateTokenPrivilege (Create a token object — создать маркерный объект), SeDebugPrivilege (Debug programs — отладка программ), SeChangeNotify-Privilege (Bypass traverse checking — пропуск проверки) и SeAssignPrimary-TokenPrivilege (Replace a process level token — изменить маркер уровня процесса). Но если регистрируется пользователь, обладающий одним или несколькими из этих полномочий, то Windows 2000 записывает в журнал событие с ID 576 (новой учетной записи назначены специальные полномочия; данное событие обычно близко следует за успешным событием регистрации с ID 528 или ID 540). Чтобы определить, какими полномочиями обладает пользователь во время регистрации, следует обратить внимание на поле Logon ID события с ID 576, которое идентифицирует пользователя, и поле Assigned, где перечислены краткие имена полномочий.
Audit Policy Change
С помощью категории Audit privilege use можно проследить, кто и когда использует полномочия, а категория Audit policy change позволяет узнать об изменениях, вносимых администраторами в назначенные полномочия. Данная категория обеспечивает контроль нескольких типов изменений политики.
Во-первых, Audit policy change сообщает, когда были изменены назначенные привилегии. Когда администратор предоставляет пользователю полномочия, Windows 2000 регистрирует событие с ID 608 (пользователю назначены полномочия). В поле User Right перечислены сокращенные имена назначенных полномочий (одного или нескольких). Поле Assigned to идентифицирует пользователя или группу, которой администратор назначил полномочия. На Экране 3 показано событие с ID 608, зарегистрированное Win-dows 2000, когда я назначил группе Administrators полномочия SeCreate-TokenPrivilege (Create a token object) и SeCreatePermanentPrivilege (Create permanent shared objects — создавать постоянные разделяемые объекты).
Поля User Name, Domain и Logon ID под заголовком Assigned By явно указывают, кто назначил полномочия. Но если администраторы NT назначают полномочия напрямую через User Manager, то администраторы Windows 2000 предоставляют или отзывают полномочия не прямо, а через объекты групповой политики (Group Policy Objects, GPO). В силу этих различий, а также поскольку локальная система пользователя читает Group Policy и вносит соответствующие изменения в назначенные полномочия, событие с ID 608 указывает в поле Assigned By учетную запись локального компьютера. Чтобы выяснить, каким образом администратор изменил полномочия, необходимо активизировать категорию Audit directory service для проверки изменений в объектах GPO в Active Directory (AD). Более подробная информация об аудите таких изменений приведена в статье «Заглянем в журнал безопасности Windows 2000».
Если полномочия пользователя отменены, то в следующий раз, когда Win-dows 2000 применит групповую политику, будет зарегистрировано событие с ID 609 (отмена полномочий пользователя). Поле User Right этого события похоже на поле User Right события с ID 608. Поле Removed From указывает пользователей и группы, лишенные одного или нескольких полномочий. Поля User Name, Domain и Logon ID в разделе Removed By указывают учетную запись локального компьютера точно так же, как поля Assigned By события с ID 608. Оба события регистрируются на компьютерах, на которых был применен GPO, содержащий назначенные полномочия. Однако изменения, произведенные в объектах GPO, регистрируются на контроллере домена (DC), к которому подсоединялся администратор, редактировавший GPO.
Audit policy change позволяет отслеживать изменения в доверительных отношениях с другими доменами. Если администратор добавляет новый доверенный домен с помощью оснастки Active Directory Domains and Trusts, то Windows 2000 регистрирует два идентичных события с ID 610 (новый доверенный домен) на DC, к которому подсоединялся администратор. Поле Do-main Name события с ID 610 идентифицирует новый доверенный домен. Чтобы выяснить, кто установил доверительное отношение, нужно посмотреть на поля User Name, Domain и Lo-gon ID под заголовком Established By.
Windows 2000 также регистрирует на DC один экземпляр события с ID 620 (изменена информация о доверенном домене). Однако данное событие не содержит никакой дополнительной информации. При удалении доверенного домена Windows 2000 регистрирует два события с ID 611 (удаление доверенного домена). Данное событие содержит те же поля, что и событие с ID 610, но поля User Name, Domain и Logon ID находятся под заголовком Removed By вместо Established By.
В событиях с ID 610, ID 611 и ID 620 проявляется еще один изъян системы аудита Windows 2000: события регистрируются при удалении и добавлении как доверяющих, так и доверенных доменов. Событие говорит лишь о том, что было установлено или прекращено доверительное отношение, но не указывает, был ли домен доверенным или доверяющим.
Windows 2000 регистрирует событие с ID 612 (изменение политики аудита) всякий раз, когда применение Group Policy приводит к изменению политики аудита компьютера. Поле New Policy данного события указывает, какие категории аудита были активизированы для регистрации успешных и неудачных действий. Например, на Экране 4 показано, что активизирован аудит успешных и неудачных изменений политики. Как и в событии с ID 608, в полях User Name, Domain и Logon ID в подразделе Changed By события с ID 612 не указано, какой администратор изменил политику аудита, так как Windows 2000 не обнаруживает изменения до тех пор, пока групповая политика не применена. Тем не менее событие с ID 612 полезно для поиска изменений в политике аудита.
Категорией Audit policy change можно воспользоваться и для отслеживания некоторых других изменений политики. Событие с ID 617 свидетельствует об изменении политики Kerberos, определяющей срок действия и обновление билета. Windows 2000 не ограничивается регистрацией события с ID 617 при явных изменениях политики Kerberos, а записывает событие в журнал всякий раз, когда DC применяет Group Policy. При изменении раздела Encrypted Data Recovery Agents групповой политики, в котором определены лица, уполномоченные восстанавливать файлы, зашифрованные с помощью EFS (Encrypting File System), Windows 2000 регистрирует событие с ID 618 (изменение политики восстановления данных). И опять, в полях User Name, Domain и Logon ID в подразделе Changed By нет информации о том, кто в действительности изменил политику; в них просто указана учетная запись локального компьютера.
Администратор может контролировать изменения политики IP Security (IPSec) компьютера, однако существуют разночтения относительно событий, обеспечивающих эту возможность. В документации Windows 2000 приводится список событий аудита IPSec — с ID 615 и ID 616 — входящих в категорию Audit policy change, но Event Viewer относит эти события к Detail tracking (категория Audit process tracking). Кроме того, Windows 2000 регистрирует подобные события, даже если категории Audit policy change и Audit process tracking не активизированы. В любом случае, при назначении политики IPSec через GPO в AD или через локальный GPO компьютера, Win-dows 2000 заносит в журнал событие с ID 615. Если используется GPO в AD, то в описании события с ID 615 указывается: IPSec PolicyAgent Service: Using the Active Local Registry policy, as (i) there’s no Active Directory Storage policy or (ii) the Active Directory Storage policy couldn’t be applied successfully and there’s no Cached policy (используется локальная политика Active Local Re-gistry, так как (i) не существует политики Active Directory или (ii) политика Active Directory не может успешно применяться и нет сохраненной политики). Если при применении политики Windows 2000 сталкивается с трудностями, она регистрирует событие с ID 616 (агент политики IPSec встретил потенциально серьезную проблему).
Контроль изменений в групповой политике — важное условие сохранения целостности сети. Но необходимо быть внимательным и при контроле за физическим доступом к системам по сети. Windows 2000 поможет решить эту задачу.
Audit system events
Категория Audit system events содержит несколько полезных событий. Всякий раз при начальной загрузке Windows 2000 регистрирует событие с ID 512 (начало работы Windows NT). С помощью данного события можно обнаружить несанкционированные попытки перезагрузки системы, которые потенциально опасны, так как Windows 2000 уязвима, когда работу завершают пользователи, имеющие физический доступ к машине.
В документации Windows 2000 указывается, что операционная система регистрирует событие с ID 513 каждый раз при завершении работы, но это утверждение неверно. Чтобы определить, как долго система была в нерабочем состоянии, нужно сравнить время и дату события с ID 512 и предыдущего события, зарегистрированного Windows 2000.
Windows 2000 отмечает в журнале событие с ID 517 (журнал аудита очищен) всегда, когда кто-нибудь очищает журнал безопасности. Windows 2000 записывает это событие в новом журнале. Событие с ID 517 может указать на взломщика, который пытался замести следы.
В процессе начальной загрузки Win-dows 2000 регистрирует и несколько других событий. Операционная система фиксирует событие c ID 515 (доверенный процесс Logon зарегистрирован в LSA) для каждой запущенной процедуры входа в систему (процедуры входа в систему обслуживаются процессом Logon, компонентом подсистемы безопасности Windows 2000). Windows 2000 также регистрирует событие с ID 514 (пакет аутентификации, загруженный LSA) для каждого пакета аутентификации, загружаемого операционной системой (пакеты аутентификации совместимы с различными протоколами аутентификации, такими, как Kerberos, NT LAN Manager (NTLM) и Secure sockets Layer (SSL)). Операционная система записывает событие с ID 518 (SAM загрузила пакет оповещения) для каждого пакета оповещения, загруженного Windows 2000; стандартные пакеты оповещения — scecli, kdcsvc и rassfm. Пакеты оповещения — это специальные DLL, которые проектируются и устанавливаются для синхронизации паролей с другими системами или реализуют специальные правила применения паролей. Однако взломщики могут использовать пакеты оповещения для кражи паролей. В любом случае к нестандартным пакетам оповещения следует относиться с осторожностью.
Полный арсенал
Windows 2000 предоставляет впечатляющий набор функций аудита, усовершенствованных по сравнению с возможностями Windows NT. Однако в системе аудита Windows 2000 имеются и значительные недостатки, а применение политик Group Policy не всегда позволяет идентифицировать пользователя, изменившего политику, так как администраторы более не изменяют политики напрямую. Хочется верить, что в дальнейшем разработчики Microsoft устранят подобные недостатки и обеспечат более полный аудит изменений политик, вносимых через GPO.

Windows 2000 и XP (Часть 3)
Модель безопасности в Win NT/2000.
Защита данных в Windows 2000 построена весьма эффективно и гарантируется многоуровневой схемой защиты как от случайной их потери при работе, так и от умышленного повреждения или нарушения условий конфиденциальности и целостности. Концепции, лежащие в основе системы безопасности операционной системы Windows 2000, нельзя назвать революционными: все основные идеи и механизмы достались ей в наследство от прежней системы Windows NT 4.0, где они уже доказали свою состоятельность и эффективность. Говоря иначе, в основе системы безопасности новой операционной системы, как и ранее, лежат понятия "дескриптора безопасности" (SD, Security Descriptor) и "списка управления доступом" (ACL, Access Control List). Но в то же время в новой операционной системе были включены дополнительные возможности (например, поистине мощные средства, которые предоставляет использование механизмов Active Directory) и получили дополнительное развитие старые средства. К сожалению, некоторые из них доступны только для тех пользователей, которые работают под Windows 2000 Professional и входят в группу, управляемую сервером на базе Windows 2000 Server. А наиболее полно они реализуемы лишь в случае создания полноценного домена с разделяемыми функциями серверов, созданными на их базе контроллерами доменов и специальными серверами, определяющими исключительно параметры безопасности. Для реализации новых идей используются различные методы; большинство из них предназначено для работы в сети, вследствие чего они малоинтересны обычному пользователю, поэтому мы вначале рассмотрим принципы, общие для любого компьютера, работающего под управлением Windows 2000.
Любое приложение (программа), запускаемое под управлением Windows 2000, автоматически начинает использовать возможности, обеспечивающие его безопасность. То есть, какое бы приложение не было бы запущено, операционная система (И ТОЛЬКО ОНА) контролирует доступ к своим ресурсам, таким как файлы, память и аппаратные устройства. Что интересно, разработчики Windows 2000 пошли еще дальше и решили централизовать доступ вообще к любым ресурсам системы (даже к таким достаточно абстракт-ным, как окна, процессы и потоки). Поэтому приложение, работающее в Windows, будет защищено от модификации исполняемого кода и данных со стороны других "некорректно" работающих приложений, да и просто нехороших людей, задумавших сломать вам систему. Кроме этого, возможно программное управление правами доступа к особенно критичным в смысле безопасности объектам со стороны отдельных пользователей. Таким образом, обеспечивается многоуровневая система защиты. Данные защищены настолько хорошо, что столкнуться с проблемами доступа к ним при этом могут даже администраторы, обладающие всеми полномочиями при управлении системой, если они не выполняют простейших правил обеспечения безопасности. Например, если не удается восстановить операционную систему после ее выхода из строя и невозможно воспользоваться сертификатом, с помощью которого производилось шифрование, то доступ к данным, хранящимся на томах хранения информации с применением EFS, будет невозможен из любой другой работающей системы, куда они будут перенесены. Поэтому сертификаты всегда желательно копировать на какой-нибудь надежный резервный носитель информации, который будет храниться в хорошо защищенном от постороннего доступа и вредных факторов воздействия месте.
Как известно, при разработке Windows 2000 учитывалось то, что она должна удовлетворять уровню безопасности C2, разработанному оборонными ведомствами США. Базовые принципы уровня безопасности C2 это:
- Выделяемая процессам память защищена таким образом, что прочитать информацию оттуда невозможно даже после того, как она уже освобождена процессом.
- Только системный администратор имеет физическую возможность управлять безопасностью системы и уровнем доступа отдельных лиц и групп лиц.
- Должно осуществляться управление доступом к ресурсам. Должно быть возможным разрешать или запрещать доступ к указанным ресурсам как отдельным пользователям, так и группам пользователей.
- Пользователи должны регистрировать себя в системе и иметь уникальные идентификаторы. Все действия пользователей, контролируемые системой, должны быть персонифицированы.
- Система должна быть защищена от вмешательства, например, от модификации системного кода в памяти или системных файлов на диске.
Эти требования учитывались уже на этапе проектирования операционной системы и лежат в основе работы самых первых версий Windows NT, поэтому Windows 2000 уже на уровне ядра поддерживает объектную модель защиты. Надо сказать, что никакая другая компромиссная реализация функций, позволяющих работать системе паролей в ранних версиях Windows, сделанная на более высоком уровне (такая, например, как применение отдельных программных пакетов или встраивание соответствующих драйверов, патчей и библиотек в операционную систему) не смогла бы предоставить такого уровня защищенности при той скорости работы, которая достигается в NT. И именно требования безопасности явились катализатором и причиной, заставившей "Майкрософт" писать совершенно новую операционную систему почти с нуля и попрощаться с веткой Windows 9x. Объектная модель защиты подразумевает, что любой ресурс рассматривается системой Windows 2000 как объект, а это означает, что он обладает своими собственными свойствами (атрибутами), которые могут описывать, в том числе, и его поведение с точки зрения безопасности, а также включает в себя данные и все те функции, которые могут потребоваться для манипулирования этими данными. Возможностью прямого доступа к объектам (а значит и к ресурсам) обладает только сама Windows 2000, остальные приложения могут осуществлять доступ к ресурсам исключительно при посредничестве операционной системы путем вызова ее функций и под контролем системы безопасности ОС. Возможности объекта определяются его типом и теми атрибутами, которые были присвоены объекту при его создании (они могут быть изменены с течением времени).
Краеугольным камнем, на котором базируется вся реализация защиты данных, является пользовательская учетная запись или на сленге администраторов и ветеранов NT - аккаунт. Учетная запись - это своего рода пропуск, который позволяет пользователю обращаться к ресурсам системы и однозначно определяет, с какими ресурсами он может работать и каким образом. Каждый пользователь, который регулярно использует компьютер, должен обладать собственной индивидуальной учетной записью. Для тех же, кто входит в систему нечасто, существует одна на всех учетная запись - гость, - которая обладает, как правило, минимумом прав доступа. Для облегчения жизни администратору (а он тоже не бог, как может показаться некоторым неискушенным людям, а всего лишь человек) несколько учетных записей можно объединить в группу и назначать унифицированные права доступа всем ее членам, а не каждому пользователю в отдельности. Это уже относится к назначению групповых политик и обычно обсуждается при рассмотрении приемов администрирования, что мы и сделаем в одной из следующих статей. Вся информация об учетных записях и группах хранится в централизованной базе данных. В Windows NT 4, а также в Windows 2000 эта база называется SAM (Security Accounts Manager). В базе данных SAM каждый пользователь и каждая группа, а также каждый компьютер идентифицируется уникальным идентификатором безопасности SID (Security Identifier), который каждый раз при создании новой учетной записи автоматически генерируется ОС совершенно случайным образом и никогда не используется повторно. Соображения уникальности заставляют систему использовать в качестве SID число, а не символьную запись. Символьные обозначения учетных записей просто ставятся в соответствие SID'у, так делается только для удобства работы администратора. Из вышесказанного вытекает, что, если вы по ошибке удалите какую-либо учетную запись, то восстановить ее будет уже невозможно, так как если вы попытаетесь создать новую запись с таким же символьным именем, ОС все равно сгенерирует новый SID, который, естественно, не будет соответствовать по наполнению пре-дыдущему. Это обстоятельство обязательно следует учитывать при работе с Windows 2000.
Атрибуты защиты каждого объекта (будь то реестр, файл или общий ресурс) находятся в его дескрипторе защиты SD, который предоставляет сведения о владельце объекта (то есть содержит SID владельца) и дискреционный список управления доступом к объекту (DACL, Discretionary Access Control List). Дискреционный список управления доступом (часто называемый просто списком управления доступом) содержит информацию о том, какие действия запрещается или разрешается выполнять тем или иным пользователям или группам пользователей по отношению к данному объекту. То есть, он представляет собой некий перечень записей управления доступом ACE (Access Control Entry), каждая из которых соответствует некоторому пользователю или группе пользователей (содержит соответствующие SID), которым разрешен или запрещен доступ к данному объекту в форме, определяемой ACE. Помимо дискреционного списка управления доступом дескриптор SD включает в себя системный список управления доступом SACL или System ACL, который необходим для работы системы аудита доступа к ресурсам (системы протоколирования). Система аудита осуществляет слежение за доступом к объектам безопасности и протоколирует информацию об удачных и неудачных попытках доступа к ним в журнале аудита. Благодаря механизмам аудита администратор может узнать, кто и когда пользовался интересующим его ресурсом системы, или пытался им воспользоваться, если в доступе было отказано.
При загрузке Windows предложит вам зарегистрироваться в системе от имени одного из пользователей, для которых имеется учетная запись. При этом введенные данные сравниваются с теми, которые хранятся в операционной системе, и на основании результата сравнения принимается решение о регистрации (или отказе в доступе). В случае успешной регистрации, пользователю системой WinLogon назначается токен доступа (access token), который в дальнейшем будет присваиваться каждому процессу, который запустит пользователь. Токен содержит информацию о самом пользователе, группе, в которую он входит, привилегиях и правах доступа, то есть содержит SID пользователя и SID'ы всех групп, в которые он входит. При попытке процесса обратиться к какому-либо объекту производится поиск ACE, соответствующего обратившемуся процессу, в дискреционном списке ACL этого объекта. На основе сравнения токена доступа и ACE принимается решение о разрешении или запрещении доступа процесса, запущенного данным пользователем к объекту. Как мы видим, уже на достаточно низком уровне система неплохо защищена от возможных попыток несанкционированного доступа.
Еще одно средство защиты данных, интегрированное в Windows 2000, - это файловая система EFS (Encrypting File System), являющаяся дополнением к NTFS 5.0 и позволяющая производить шифрование файлов "на лету", т. е. как шифрование, так и дешифровка прозрачны для пользователя и для программ. Степень криптостойкости у этого метода на удивление высокая, что обеспечивается применением шифрования с комбинированным несимметричным (открытым) ключом, в который, к тому же, вносятся псевдослучайные изменения. При первой попытке зашифровать некоторый файл пользователю выдается системой сертификат, который содержит всю необходимую информацию по дешифровке и управлению безопасностью. Этот сертификат всегда желательно скопировать на какой-нибудь надежный носитель, поскольку в случае его утраты невозможно будет открыть ни один из зашифрованных файлов (система сообщит вам, что у вас нет прав доступа к нему). Ну и напоследок, хочется заметить, что EFS частично входит в ядро Windows, что позволяет наиболее эффективно обеспечивать сокрытие данных.
Отвлечемся от одиноко стоящей рабочей станции и обратим свои взоры к ЛВС. Что отличает сеть от простого компьютера? Правильно, наличие каналов обмена информацией, не всегда защищенных от постороннего воздействия и контроля, между отдельными хостами. А раз так, то наиболее критичную информацию необходимо как-то шифровать. Что касается целостности данных, то этим занимаются службы протоколов, ну а проблемы конфиденциальности решаются по-разному. Аутентификация на этапе соединения двух (или более) компьютеров позволяет произвести проверку того, что на другом конце линии действительно тот, с кем вы хотите связаться. Но к каналу связи (даже оптоволоконному) всегда можно подключиться, не говоря уже о том, что пакет данных при пересылке зачастую минует много серверов и маршрутизаторов, на которых он может быть перехвачен. Здесь на помощь приходит шифрование, к которому и прибегают все чаще и чаще в последние годы, если необходимо работать с хоть сколько нибудь ценными данными.
В Windows 2000 широко используются алгоритмы шифрования данных с открытым ключом, и они уже изначально встроены в систему. В первую очередь, эти средства позволяют по защищенным каналам обмениваться информацией внутри домена. Основа всей системы сетевой безопасности в Windows 2000 - это набор протоколов и методов взаимодействия с общим названием (уже одно оно очень многого стоит!) Kerberos. Эта спецификация предоставляет возможность установления защищенного канала связи между двумя хостами в незащищенной сети с их предварительной аутентификацией. В отличие от протокола Kerberos, который больше подходит для открытых сетей, средства безопасности протокола IP обеспечивают защищенность всей сети. При этом возможно централизованное управление безопасностью и назначением профилей безопасности. Данные предохраняются от перехвата и копирования на протяжении всего пути следования. Для надежной передачи информация шифруется с применением открытых или закрытых ключей. Шифрование с открытым ключом требует больших затрат ресурсов и поэтому применяется только в тех случаях, когда объем данных сравнительно невелик. Если объем большой, то они шифруются с применением закрытого ключа, который затем шифруется открытым.
Еще одна очень удобная возможность обеспечить сохранность данных при передаче их по сети - это использование политик безопасности IP. Защита данных в этом случае также обеспечивается применением алгоритмов шифрования и сертифицирования (Diffie-Hellman, HMAC, DES-CBC), причем они "прозрачны" как для клиентских программ, так и для пользователей. Предполагается, что путь следования данных с одного компьютера на другой неизвестен и, возможно, небезопасен.
Теория и практика аудита и восстановления паролей Windows NT/2000/XP

Операционные системы Windows NT/2000/XP хранят пароли в зашифрованном виде, называемом хэшами паролей (hash (англ.) - смесь, мешанина). Пароли не могут быть получены непосредственно из хэшей. Восстановление паролей заключается в вычислении хэшей по возможным паролям и сравнении их с имеющимися хэшами паролей. Аудит паролей включает в себя проверку возможных путей получения информации об учетных записях пользователей, результатом восстановления паролей является их представление в явном виде с учетом регистра.
Получение хэшей паролей
Существует несколько путей получения хэшей паролей, зависящих от их местонахождения и имеющегося доступа. Хэши паролей могут быть получены следующими способами: из файла SAM или его резервной копии, непосредственно из реестра операционной системы локального или удаленного компьютера, из реестра или Active Directory локального компьютера или удаленного компьютера внедрением DLL, посредством перехвата аутентификационных пакетов в сети.
Получение хэшей паролей из файла SAM
Учетные записи пользователей, содержащие в том числе имя пользователя и его пароль, хранятся в реестре Windows NT/2000/XP, а именно в той его части, которая находится в файле SAM (Security Account Manager (англ.) - диспетчер защиты учетных записей). Этот файл можно найти на диске в каталоге %SystemRoot%\system32\config, на диске аварийного восстановления системы или на резервной магнитной ленте.
К файлу SAM в каталоге %SystemRoot%\system32\config нельзя получить доступ, пока Windows NT/2000/XP загружена, так как он открыт операционной системой. Если имеется физический доступ к машине, необходимо скопировать файл, загрузив на этой машине другую копию операционной системы или другую операционную систему. Если Windows NT /2000/XP установлена на диске с файловой системой NTFS, то для MS-DOS и Windows 95/98/Me дополнительно нужны программы, обеспечивающие доступ к диску с NTFS из этих операционных систем. В MS-DOS могут быть использованы NTFSDOS и NTFSDOS Professional, в Windows 95/98/Me - NTFS for Windows 98 (авторами являются Mark Russinovich, Bryce Cogswell). Для доступа из операционной системы Linux требуется включение поддержки NTFS. Также можно загрузиться с дискеты и скопировать файл SAM, предварительно запустив обеспечивающую доступ к разделам с NTFS программу. После этого нужно выполнить импорт файла SAM. Извлечение хэшей паролей из файла SAM было разработано и впервые реализовано в программе SAMDump (автор Дмитрий Андрианов). При импорте файла SAM осуществляется получение списка учетных записей пользователей, содержащихся в файле SAM. Процесс импорта файла SAM подобен получению хэшей паролей методом pwdump за исключением того, что вместо функций Windows API, обеспечивающих работу с реестром Windows, используется их эмуляция. При выполнении импорта файла SAM из программы SAMDump все нелатинские буквы, имеющиеся в именах пользователей, будут искажены. Программа LC+4 лишена этого недостатка.
Другой способ получить файл SAM в операционной системе Windows NT, причем не требующий перезагрузки машины, - это копирование его из каталога %SystemRoot%\repair или с диска аварийного восстановления. Каждый раз, когда в Windows NT создается диск аварийного восстановления с помощью программы RDISK, файл SAM запаковывается и сохраняется в файл sam._, являющийся резервной копией файла SAM. Файл sam._ представляет из себя архив в формате cabinet. Этот файл может быть распакован командой "expand sam._ sam". Недостатком этого способа является то, что с момента создания диска аварийного восстановления пароли могли измениться и, возможно, файл sam._ содержит устаревшие данные. В программе LC+4 имеется встроенная возможность импорта файла SAM и из файла sam._, избавляющая от необходимости использования программы expand. При импорте списка учетных записей пользователей из файла sam._ он предварительно распаковывается, затем выполняется непосредственно импорт файла SAM.
Файл SAM также копируется, когда создается полная резервная копия. Если имеется доступ к резервной копии, можно восстановить файл SAM из %SystemRoot%\system32\config на другую машину и затем извлечь из него хэши паролей. Недостатком и этого способа также является то, что с момента последнего сеанса создания резервной копии пароли могли измениться.
Существует служебная программа SYSKEY, впервые появившаяся в составе Service Pack 3 для Windows NT. Программа SYSKEY дополнительно зашифровывает хэши паролей учетных записей, что делает импорт файла SAM вышеупомянутым способом бесполезным. SYSKEY может использоваться в одном из трех вариантов:

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

Подробнее о программе SYSKEY можно прочитать в статье KB143475 Windows NT System Key Permits Strong Encryption of the SAM.
Служебная программа SYSKEY в операционной системе Windows NT для дополнительной защиты паролей учетных записей после установки Service Pack соответствующей версии должна быть активизирована вручную. В операционных системах Windows 2000/XP программа SYSKEY изначально присутствует и активизирована.
Получение хэшей паролей из реестра операционной системы
При получении хэшей паролей из реестра операционной системы осуществляется непосредственный доступ к реестру. Для выполнения импорта информации необходимо иметь административные права на компьютере, дамп паролей учетных записей которого требуется создать. Если компьютер не является локальным, то должен быть разрешен удаленный доступ к реестру и иметься соответствующие права. Получение хэшей данным способом впервые стало возможным в программе pwdump (автор Jeremy Allison). При выполнении импорта информации этим способом с помощью программы pwdump имена пользователей, содержащие нелатинские буквы, будут искажены. Для получения хэшей паролей из реестра рекомендуется воспользоваться LC+4.
Если программа SYSKEY активизирована, хэши паролей дополнительно зашифровываются. Выполнение импорта при этом становится бесполезным так же, как и импорт файла SAM, т.к. пароли по дополнительно зашифрованным хэшам восстановлены не будут.
Получение хэшей паролей внедрением DLL
Данный метод был разработан и реализован в программе pwdump2(автор Todd A. Sabin). Получение хэшей паролей методом pwdump2 возможно вне зависимости от того, была активизирована программа SYSKEY, или нет. Для создания дампа паролей методом pwdump2 необходимо иметь право SeDebugPrivilege. По умолчанию только пользователи группы администраторов имеют его, поэтому нужно иметь административные права для использования этого метода. Использование метода pwdump2 возможно только на локальной машине.
Метод pwdump2 использует для создания дампа паролей способ, называемый внедрением DLL. Один процесс вынуждает другой процесс (lsass.exe), используя его идентификатор процесса, загружать DLL (samdump.dll) и выполнять некоторый код из DLL в адресном пространстве другого процесса (lsass.exe). Загрузив samdump.dll в lsass (системная служба LSASS - Local Security Authority Subsystem), программа использует тот же самый внутренний API, что msv1_0.dll, чтобы обратиться к хэшам паролей. Это означает, что она может получить хэши без выполнения таких действий, как перемещение их из реестра и дешифрование. Программа не заботится ни о том, каковы алгоритмы шифрования, ни каковы ключи.
В версии программы pwdump2, поддерживающей Active Directory, имеется ошибка, не позволяющая получить хэши паролей, если в операционной системе есть учетные записи с нелатинскими буквами в именах. В программе LC+4 ошибка исправлена, поэтому получение хэшей паролей данным методом рекомендуется выполнять в ней.
Метод, использующийся в программе pwdump2, был доработан для получения хэшей паролей не только с локальной, но и с удаленной машины в программах pwdump3/pwdump3e (автор Phil Staubs). На удаленный компьютер копируются исполняемый файл службы и файл DLL. После копирования файлов на удаленном компьютере создается и запускается новая служба, выполняющая те же действия, что и программа pwdump2 на локальном компьютере. Далее выполняется удаление службы и файлов, ранее скопированных. Передача информации об учетных записях пользователей производится через раздел реестра на удаленном компьютере, временно создаваемый и уничтожаемый после завершения копирования данных. В программе pwdump3e выполняется дополнительное шифрование передаваемых данных по алгоритму Diffie-Hellman для сохранения конфиденциальности при их возможном перехвате при передаче по сети. Использование данного метода также требует административных прав на той машине, информацию об учетных записях пользователей с которой хочется получить.
При выполнении импорта информации этим способом с помощью программ pwdump3/pwdump3e имена пользователей, содержащие нелатинские буквы, будут искажены. Для получения хэшей паролей с удаленного компьютера внедрением DLL рекомендуется воспользоваться LC+4.
Если административные права на локальном компьютере отсутствуют, можно воспользоваться уязвимостью операционных систем Windows NT/2000/XP, заключающейся в замене экранной заставки, запускаемой при отсутствии регистрации пользователя операционной системы в течение некоторого времени (по умолчанию интервал времени составляет 15 минут для Windows NT/2000, 10 минут - для Windows XP). Для этого файл %SystemRoot%\system32\logon.scr заменяется на требуемый исполняемый файл (например, cmd.exe), который будет запущен операционной системой вместо экранной заставки с правами системы. Замена может быть выполнена способом, используемым при копировании файла SAM. Доступ к диску с NTFS с возможностью записи осуществим с помощью NTFSDOS Professional или NTFS for Windows 98. Далее выполняются действия по получению хэшей методом pwdump2 или pwdump3/pwdump3e.
Перехват аутентификационных пакетов в сети
Даже если программа SYSKEY установлена и активизирована, не имеется необходимого доступа к удаленному или локальному компьютеру, существует возможность получения хэшей паролей учетных записей пользователей. Этим способом является перехват аутентификационных пакетов в сети (sniffing (англ.) - вынюхивание). Клиентская машина обменивается с сервером аутентификационными пакетами каждый раз, когда требуется подтверждение прав пользователя. Необходимо, чтобы компьютер находился в сетевом сегменте пользователя или ресурса, к которому он обращается. Программа для перехвата аутентификационных пакетов (sniffer (англ.) - вынюхиватель), встроенная в LC4, работает на машинах с Ethernet-адаптером и в Windows NT/2000/XP, и в Windows 95/98/Me. Программу LC4 в режиме перехвата аутентификационных пакетов нужно оставить запущенной на некоторое время для сбора достаточного количества хэшей паролей. Полученные данные необходимо сохранить в файл, после чего в программе LC+4 выполнить импорт файла сеанса LC4.
Для препятствования получения хэшей паролей этим способом фирмой Microsoft было разработано расширение существующего механизма аутентификации, называемое NTLMv2. Его использование становится возможным после установки Service Pack, начиная с Service Pack 4 для Windows NT. Подробнее об использовании NTLMv2 можно прочитать в статье KB147706 How to Disable LM Authentication on Windows NT.
Восстановление паролей
Пароль может быть получен различными способами: атакой по словарю, последовательным перебором и гибридом атаки по словарю и последовательного перебора.
При атаке по словарю последовательно вычисляются хэши для каждого из слов словаря или модификаций слов словаря и сравниваются с хэшами паролей каждого из пользователей. При совпадении хэшей пароль найден. Преимущество метода - его высокая скорость. Недостатком есть то, что таким образом могут быть найдены только очень простые пароли, которые имеются в словаре или являются модификациями слов словаря.
Последовательный перебор комбинаций (brute force (англ.) - грубая сила (дословно), решение "в лоб") использует набор символов и вычисляет хэш для каждого возможного пароля, составленного из этих символов. При использовании этого метода пароль всегда будет определен, если составляющие его символы присутствуют в выбранном наборе. Единственный недостаток этого метода - большое количество времени, которое может потребоваться на определение пароля. Чем большее количество символов содержится в выбранном наборе, тем больше времени может пройти, пока перебор комбинаций не закончится.
При восстановлении паролей гибридом атаки по словарю и последовательного перебора к каждому слову или модификации слова словаря добавляются символы справа и/или слева. Для каждой получившейся комбинации вычисляется хэш, который сравнивается с хэшами паролей каждого из пользователей.
После получения хэшей паролей можно начать восстановление паролей. Двумя основными типами файла, содержащими хэши паролей, являются PwDump- (passwords dump (англ.) - дамп паролей) и Sniff-файл.
Каждая строка PwDump-файла имеет следующий формат:
"ИмяПользователя:RID:LM-хэш:NT-хэш:ПолноеИмя,Описание:ОсновнойКаталогПользователя:"
Каждая из 7-символьных половин пароля зашифрована независимо от другой в LM-хэш по алгоритму DES (бывший федеральный стандарт США), NT-хэш получается в результате шифрования всего пароля по алгоритму MD4 (фирмы RSA Security, Inc.). LM-хэш содержит информацию о пароле без учета регистра (в верхнем регистре), а NT-хэш - с учетом регистра. После имени пользователя имеется уникальный идентификатор учетной записи RID (relative identifier (англ.) - относительный идентификатор), который для получения хэшей не используется. Идентификатор встроенной учетной записи администратора равен 500, гостевой учетной записи - 501. LM-хэш присутствует для совместимости с другими операционными системами (LAN Manager, Windows for Workgroups, Windows 95/98/Me и т.д.). Его наличие упрощает восстановление паролей. Если длина NT-пароля превышает 14 символов, LM-хэш соответствует пустому паролю. При существовании LM-хэша восстановление сначала осуществляется по LM-хэшу, после нахождения LM-пароля используется NT-хэш для определения NT-пароля.
Каждая строка Sniff-файла имеет следующий формат:
"ИмяПользователя:3:ЗапросСервера:LM-ответ:NT-ответ"
LM-ответ получается в результате шифрования LM-хэша, NT-ответ - в результате шифрования NT-хэша. Шифрование выполняется по алгоритму DES таким образом, что определить LM- и NT-пароль можно только при проверке всего пароля. Кроме того, в каждом случае используется свой запрос сервера. Поэтому на определение паролей по Sniff-файлу потребуется значительно больше времени.
Первой программой, выполняющей восстановление паролей Windows NT, была L0phtCrack (сегодняшнее название - LC4). Авторами L0phtCrack являются Peiter Mudge Zatko и Chris Wysopal из фирмы L0pht Heavy Industries, Inc. (сейчас @stake, Inc.). При использовании нелатинских букв в пароле с помощью программы LC4 пароль найден не будет, для восстановления паролей рекомендуется использовать LC+4.
Изменение паролей пользователей без их восстановления
Если восстановление паролей пользователей Windows NT/2000/XP не требуется, возможно их изменение при имеющемся доступе к локальному компьютеру. Изменение паролей делается с помощью программы Offline NT Password & Registry Editor (автор Petter Nordahl-Hagen). Выполняется загрузка с дискеты с операционной системой Linux, выбор пользователя для изменения пароля, вычисление хэша пароля и модификация файла SAM на диске с операционной системой. Программа поддерживает Windows NT/2000/XP, в т.ч. с активизированной служебной программой SYSKEY.
Дополнительные возможности получения информации о паролях
Если в сети есть машины с установленными на них операционными системами Windows 3.11, Windows for Workgroups или Windows 95/98/Me, то имеются дополнительные возможности получения информации о паролях.
По умолчанию в этих операционных системах выполняется кэширование паролей пользователей на диск в файлы %WinDir%\<эИмяПользователя>.pwl (PassWord List (англ.) - список паролей). Пароли хранятся в зашифрованном виде, причем регистр букв игнорируется (всегда используется верхний регистр). Алгоритм шифрования паролей начиная с Windows 95 OSR2 был изменен, так как была исправлена обнаруженная ошибка, поэтому восстановить пароли из старых PWL-файлов значительно проще. Для этого могут быть применены программы Glide (автор Frank Andrew Stevenson), PWL_Key (автор Артур Иванов), PwlHack (автор Владимир Калашников), PwlTool (авторами являются Vitas Ramanchauskas, Евгений Королев). Для восстановления паролей из новых PWL-файлов можно использовать PwlHack или PwlTool.
При разрешенном кэшировании паролей с момента входа и регистрации пользователя в Windows и до момента выхода пароли можно определить, запустив программу PwlView (авторами являются Vitas Ramanchauskas, Евгений Королев). Показываются кэшируемые пароли на локальной машине для текущего пользователя, используя недокументированные функции Windows API.
Если пользователь Windows NT/2000/XP является одновременно пользователем Windows 3.11, Windows for Workgroups или Windows 95/98/Me и будет определен его пароль (как пользователя Windows 3.11, Windows for Workgroups или Windows 95/98/Me), в котором, как уже упоминалось ранее, содержатся только символы верхнего регистра, то с помощью LC+4 пароль Windows NT/2000/XP может быть легко определен. Необходимо в качестве известных символов пароля указать символы ранее определенного пароля пользователя Windows 3.11, Windows for Workgroups или Windows 95/98/Me.
Рекомендации администратору Win3.11,Win for Workgroups и Win95/98/Me
На машинах с Win3.11,Win for Workgroups и Win95/98/Me:

отключить кэширование паролей в Windows 3.11 и Windows for Workgroups. Для этого в файле %WinDir%\system.ini добавить следующий параметр:
[NETWORK]
PasswordCaching=no
отключить кэширование паролей в Windows 95/98/Me. Для этого с помощью редактора реестра найти в реестре двоичный параметр DisablePwdCaching и установить его в 1 (создав его, если он не существовал) в разделе
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Network
после отключения кэширования паролей удалить все PWL-файлы с диска и перезагрузить операционную систему;
если конфигурация компьютера удовлетворяет системным требованиям операционных систем Windows NT/2000/XP, перейти на их использование.

Настройки безопасности в Windows

Новости

Установка разрешения из командной строки

Устранение проблем с разрешениями

Агент восстановления данных

сгенерированный ключ шифрования записывается на локальный жесткий диск в зашифрованном виде;

Рекомендации администратору Windows NT/2000/XP