- •Лабораторная работа 1 обзорная информация о реестре windows 2000
- •Теоретическое обоснование
- •1. Историческая справка по реестру
- •1.1. Неудобства работы с ini-файлами
- •1.2. Назначение реестра
- •2. Создание нового аппаратного профиля
- •3. Установка нового устройства
- •1. Структура реестра
- •Лабораторная работа 2 структура реестра windows 2000
- •Теоретическое обоснование
- •2. Хранение данных реестра
- •3. Процесс внесения изменения в параметры реестра
- •3.1. Атомарность и восстановление ульев реестра
- •3.2. Сброс данных (flushing data)
- •4. Ограничение по размеру реестра
- •Лабораторная работа 3 использование редактора реестра
- •1. Назначение и способы запуска редактора реестра
- •1.1. Использование программы Regedit
- •1.2. Запуск Regedit
- •2. Пользовательский интерфейс и возможности программы
- •2.1. Исследование интерфейса Regedit
- •2.2. Команды меню Registry
- •2.2.1. Экспорт ветви реестра
- •2.3. Команды меню Edit
- •2.4. Команды меню View
- •2.5. Меню Favorites
- •Лабораторная работа 4
- •1. Резервное копирование и восстановление реестра в Windows 2000 с помощью утилиты BackUp
- •1.1. Резервное копирование и восстановление системных файлов конфигурации
- •1.1.1. Резервное копирование системных конфигурационных файлов
- •1.1.2. Восстановление системных конфигурационных данных
- •2. Диск аварийного восстановления
- •2.1. Процедура изготовления erd для Windows 2000
- •3. Консоль восстановления Windows 2000
- •3.1. Способы запуска Recovery Console
- •3.1.1. Запуск Recovery Console из программы Windows 2000 Setup
- •3.1.2. Установка Recovery Console через файл Boot.Ini
- •3.1.3. Удаление Recovery Console
- •3.2. Использование Recovery Console
- •4. Аварийное восстановление реестра Windows 2000
- •4.1. Аварийное восстановление системы с помощью erd
- •Ручное резервное копирование и восстановление реестра
- •4.3. Экспорт и импорт файлов реестра
- •4.4. Резервное копирование с помощью утилит Resource Kit
- •4.4.1. Утилита reg из Windows 2000 Resource Kit
- •Лабораторная работа 5 исследование надежности ос
- •Теоретическое обоснование
- •1.1. Простейший способ редактирования файла Boot.Ini
- •1.2. Ручное редактирование файла Boot.Ini
- •1.3. Формат файла Boot.Ini
- •1.3.1. Раздел [boot loader]
- •1.3.2. Раздел [operating systems]
- •2. Индивидуальная настройка регистрации в системе для
- •2.1. Изменение графического файла, отображаемого при регистрации в системе
- •2.2. Добавление сообщения, отображаемого при регистрации пользователей в системе
- •2.3. Добавление информационного сообщения путем непосредственного редактирования реестра
- •3. Методы индивидуальной настройки ос Windows 2000
- •3.1. Автоматизация процесса регистрации в системе
- •3.2. Маскирование имени последнего регистрировавшегося пользователя в окне регистрации
- •3.3. Конфигурирование системных папок
- •3.4. Другие популярные методы индивидуальной настройки
- •3.4.1. Отключение функции AutoRun для компакт-дисков
- •3.4.2. Переименование мусорной корзины
- •3.4.3. Изменение значка мусорной корзины
- •3.4.4. Удаление стрелок с ярлыков
- •Лабораторная работа 7 исследование алгоритмов планирования потоков с приоритетами
- •Теоретическое обоснование
- •Лабораторная работа 8 исследование методов защиты реестра
- •Теоретическое обоснование
- •1. Требования к операционной системе, защищенной по классу с2
- •2. Мероприятия по защите реестра от несанкционированного изменения
- •2.1. Простейшие меры ограничения доступа к реестру
- •2.2. Дополнительные меры защиты Windows 2000
- •2.3. Редактирование прав доступа к ключам реестра
- •2.3.1. Обзор стандартных прав доступа в Windows 2000
- •2.3.2. Права доступа по умолчанию к объектам файловой системы и реестра Windows 2000
- •2.3.3. Наиболее важные ключи реестра Windows nt/2000, нуждающиеся в защите
- •2.4. Защита реестра от несанкционированного удаленного доступа
- •2.5. Защита ульев sam и Security
- •2.5.1. Как защитить улей sam
- •2.6. Ограничение анонимного доступа к компьютеру
- •2.6.1. Использование оснастки ммс Local Security Policy
- •2.7. Системный планировщик как еще одна потенциальная угроза безопасности
- •Вопросы для защиты работы
- •Лабораторная работа 9
- •Теоретическое обоснование
- •1. Возможности ос Windows 2000 по управлению рабочими средами пользователей
- •2. Назначение и возможности пользовательских профилей
- •2.1. Базовая информация о пользовательских профилях
- •2.2. Параметры, хранящиеся в пользовательском профиле
- •2.3. Структура пользовательского профиля
- •2.3.1. Файл Ntuser.Dat
- •2.3.2. Блуждающие профили
- •3. Назначение и возможности системной политики
- •3.1. Обзорные сведения о системной политике
- •3.2. Административные шаблоны
- •3.2.1. Параметры безопасности
- •3.4.1. Файл Gpt.Ini
- •3.5. Локальные объекты групповой политики
- •3.5.1. Папки шаблона групповой политики
- •3.3. Инкрементные шаблоны безопасности
- •3.4. Шаблон групповой политики
- •3.5.2. Файлы Registry.Pol
- •Список рекомендуемой литературы
- •090105 «Комплексное обеспечение информационной безопасности автоматизированных систем»
- •3 55029, Г. Ставрополь, пр. Кулакова, 2
3. Процесс внесения изменения в параметры реестра
3.1. Атомарность и восстановление ульев реестра
Реестр гарантирует атомарность (atomicity) отдельных действий. Это означает, что любое изменение, выполненное по отношению к значению (установка, удаление или сохранение) либо работает, либо нет. За счет этого исключается возможность появления поврежденных комбинаций из старых и новых значений. Такое повреждение не произойдет, даже если в процессе внесения изменений в реестр система внезапно остановится вследствие прекращения подачи питания, аппаратного сбоя или проблем с программным обеспечением. К примеру, если приложение устанавливает значение реестра, и в этот момент происходит остановка системы, то после перезагрузки значение реестра будет иметь прежнее значение или новое значение, но бессмысленная комбинация старого и нового значений не появится никогда. Кроме того, размер и временные данные для ключа, содержащего значение, в которое вносились изменения, будут точными, вне зависимости от того, было изменено это значение или нет.
3.2. Сброс данных (flushing data)
Windows NT 4.0 и Windows 2000 записывают данные в реестр только после того, как происходит сброс (flush). Сброс происходит после того, как измененные данные "постареют" на несколько секунд. Кроме того, сброс может произойти и по прямому запросу приложения, которое намеренно сбросило данные на жесткий диск.
Для всех ульев (кроме \System) система выполняет следующую процедуру сброса:
1. Все измененные данные записываются в файл журнала (LOG-файл) соответствующего улья, вместе с указанием их точного местоположения в улье. После этого выполняется сброс, и все измененные данные оказываются записанными в файл журнала.
2. Первый сектор файла улья помечается, что указывает на переходное состояние данного файла.
3. Измененные данные записываются в файл улья.
4. После этого файл улья помечается как файл, выполнение транзакции над которым завершилось.
Для улья \System используется другой процесс сброса, т. к. этот улей является жизненно важным элементом, данные которого считываются при запуске системы. Кроме того, при запуске системы его использование начинается гораздо раньше, чем других ульев, поскольку в его состав входит ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control, содержащий параметры, необходимые при инициализации реестра в процессе загрузки. Так, параметры, расположенные в составе ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist, используются при поиске остальных файлов ульев реестра. Если улей \System поврежден, то он не может быть восстановлен с помощью описанной выше процедуры.
Файл System.alt содержит копию данных файла System. Во время сброса данных изменения помечаются, записываются и затем помечаются как выполненные. После этого точно такой же процесс сброса выполняется для файла System.alt. Если на любой стадии процесса происходит отключение питания, аппаратный или программный сбой, то корректная информация может быть найдена либо в файле System, либо в файле System.alt.
Файл System.alt аналогичен файлу LOG, с тем исключением, что во время загрузки система вместо того, чтобы повторно вносить изменения, зарегистрированные в LOG-файле, просто переключается на использование файла System.alt. Файл System.alt не нужен, если файл System не находится в переходном состоянии.
