Лабораторный практикум по НСД 2013

401

6)Найдите и выберете произвольный исполняемый файл (*.exe), нажав кнопку «Открыть».

7)В поле «Отслеживать запуск следующих приложений», выделите добавленное приложение.

Рис. 18.11. Окно настроек контроля целостности

8)В нижней части текущего окна, в поле «Запуск» нажмите на «Разрешить», после чего эта надпись изменится на «Запросить действие». Таким образом произведено ограничение на запуск выбранного приложения.

9)Сохраните изменения настроек, нажав кнопку «ОК» окна «Настройка: контроль целостности», а затем кнопку «Применить» главного окна настроек программы.

10)Найдите и попробуйте запустить выбранное в пункте 10 приложение.

11)Проанализируйте работу антивируса, сделайте скрин-шот сообщения антивируса.

12)Отмените произведенные ранее настройки «Антивируса Касперского 7.0», удалив добавленное в пункте 10 приложение из списка контролируемых.

Подготовка отчёта

1)В отчете кратко опишите выполненные действия.

2)Затем в качестве полученных результатов предоставьте скрин-шоты сообщений антивируса.

3)Приведите анализ полученных в работе результатов.

402

Тестовые задания к лабораторной работе № 18

Входной контроль

1.Средство защиты от НСД – это:

a)программное, техническое или программно-техническое средство, предназначенное для предотвращения или существенного затруднения несанкционированного доступа;

b)программное, техническое или программно-техническое средство, предназначенное для полного и гарантированного предотвращения несанкционированного доступа;

c)нет верного ответа.

2.Основные компоненты защиты, реализованные в программе «Антивирус Касперского 7.0»:

a)Файловый Антивирус;

b)Почтовый Антивирус;

c)Веб-Антивирус;

d)Проактивная защита.

3.Компонент, который запускается при старте операционной системы, постоянно находится в оперативной памяти компьютера и проверяет все почтовые сообщения, это:

a)Файловый Антивирус;

b)Почтовый Антивирус;

c)Веб-Антивирус;

d)Проактивная защита.

4.Компонент, который защищает информацию, поступающую на компьютер по HTTP-протоколу, а также предотвращает запуск на компьютере опасных скриптов, это:

a)Файловый Антивирус;

b)Почтовый Антивирус;

c)Веб-Антивирус;

d)Проактивная защита.

5.Компонент, который запускается при старте операционной системы, постоянно находится в оперативной памяти компьютера и проверяет все открываемые, сохраняемые и запускаемые файлы, это:

a)Файловый Антивирус;

b)Почтовый Антивирус;

c)Веб-Антивирус;

d)Проактивная защита.

6.Компонент, который защищает не только от известных угроз, но и от новых, информация о которых отсутствует в базах приложения, это:

a)Файловый Антивирус;

403

b)Почтовый Антивирус;

c)Веб-Антивирус;

d)Проактивная защита.

7.Проверка почтовых сообщений осуществляется по протоколам:

a)IMAP;

b)ACAP;

c)DMSP;

d)MAPI1;

e)NNTP.

8.Обращение пользователя или некоторой программы к каждому файлу перехватывается компонентом «Файловый Антивирус»:

a)да;

b)нет;

c)не определено.

9.Веб-Антивирус состоит из двух модулей, обеспечивающих:

a)защиту FTP-трафика;

b)защиту HTTP-трафика;

c)защиту HTTPS-трафика;

d)проверку скриптов;

e)проверку исходных кодов программ.

10.Проактивная защита Антивируса Касперского построена на основе:

a)реактивных технологий;

b)превентивных технологий;

c)ревентивных технологий;

d)нет верного ответа.

Выходной контроль

1.Процесс проверки файлов может включать следующие действия:

a)лечение и перемещение в карантин;

b)удаление;

c)анализ на присутствие вирусов;

d)передача на анализ в веб-центр поддержки;

e)нет верного ответа.

2.Правила, по которым осуществляется проверка почты, можно разбить на следующие группы:

a)параметры, определяющие защищаемый поток сообщений;

b)параметры, задающие список объектов, которые не проверяются Почтовым Антивирусом;

c)параметры, определяющие использование методов эвристического анализа Почтовым Антивирусом;

d)параметры, определяющие список проверяемых почтовых протоколов;

404

e)параметры, определяющие действия над опасными объектами почтовых сообщений.

3.К опасным действиям, фиксируемым Проактивной Защитой, не относятся:

a)самокопирование некоторой программы;

b)изменения файловой системы;

c)встраивание модулей в другие процессы;

d)скрытие процессов в системе;

e)изменение определенных ключей системного реестра;

f)нет верного ответа.

4.Файловый Антивирус проверяет наличие информации о перехваченном файле в:

a)базе iVirus™;

b)базе iChecker™;

c)базе iSwift™;

d)базе iFolder™.

5.Если в файле обнаружен код, который похож на вредоносный, то этот файл:

a)удаляется;

b)подвергается лечению;

c)проходит повторную проверку;

d)отправляется в карантин;

e)сразу же становится доступным для работы;

f)нет верного ответа.

6.Если тело или вложение письма содержит вредоносный код, Почтовый Антивирус:

a)передает письмо пользователю;

b)удаляет письмо;

c)помещает копию зараженного объекта в резервное хранилище и пытается обезвредить объект;

d)блокирует письмо;

e)нет верного ответа.

7.Почтовый Антивирус имеет специальные модули для работы с почтовыми клиентами:

a)«Microsoft Office Outlook»;

b)«The Bat!»;

c)«DreamMail»;

d)«Mozilla Thunderbird».

8.Пользователь может настроить ряд параметров Веб-Антивируса, направленных на повышение скорости работы компонента, а именно:

a)определить алгоритм проверки;

405

b)определить скорость проверки;

c)сформировать список адресов, содержанию которых пользователь не доверяет;

d)сформировать список адресов, содержанию которых пользователь доверяет;

e)нет верного ответа.

9.Если веб-страница или объект, к которому обращается пользователь, содержат вредоносный код, то Веб-Антивирус:

a)разрешает доступ к нему;

b)разрешает ограниченный доступ к нему;

c)блокирует доступ к нему;

d)лечит его.

10.Сразу после запуска компьютера Проактивная защита анализирует следующие аспекты:

a)целостность программных модулей установленных на компьютере приложений;

b)каждую попытку изменения файловой системы;

c)действия каждого запускаемого на компьютере приложения;

d)каждую попытку изменения системного реестра;

e)нет верного ответа.

406

4.8.3.ЛАБОРАТОРНАЯ РАБОТА № 19: КОНТРОЛЬ ВОССТАНОВЛЕНИЯ БАЗЫ ДАННЫХ ПРИ РАЗНЫХ СЦЕНАРИЯХ ПОТЕРИ/ПОВРЕЖДЕНИЯ ФАЙЛОВ, ФИЗИЧЕСКОГО КОПИРОВАНИЯ И АРХИВИРОВАНИЯ ДАННЫХ

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

Сценарий проведения работы

1.База данных переведена в режиме noarchivelog (не архивируется). Имеется «холодная» резервная копия файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.

2.База данных находится в режиме archivelog (архивируется). Формируем «горячую» резервную копию файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.

3.База данных находится в режиме archivelog (архивируется). Выполняется длинная транзакция, в ходе выполнения которой формируется несколько файлов журнализации. Затем происходит внезапная остановка базы данных (shutdown abort), после которой «теряются» незаархивированные оперативные файлы журнализации. Требуется восстановить базу данных с созданием новых файлов журнализации.

Реализация сценария лабораторной работы

1. База данных переведена в режиме noarchivelog (не архивируется). Имеется «холодная» резервная копия файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.

Лабораторная работа выполняется копированием нижеприводимых команд и выполнением их в окне SQL*Plus.

407

Остановим БД, чтобы потом смонтировать ее (startup mount) для обеспечения возможности перевода ее в режим noarchivelog

connect sys/admin1 as sysdba shutdown immediate

startup mount

alter database noarchivelog;

Вот теперь откроем БД alter database open;

Получим справку о режиме архивации archive log list;

Теперь видно, что нет log файла для архивациии

Восстановим к первоначальному «эталонному» виду таблицу dept, которая могла быть изменена предыдущим выполнением archive_mod.sql;

delete from scott.dept where deptno=1; select * from scott.dept;

commit;

Теперь сформируем «холодную» копию файлa users01.dbf. Копию именно этого файла мы сделаем потому, что далее именно этот файл будет «испорчен» (на самом деле − удален), имитируя неисправность БД, требующую восстановления с использованием «холодной» (полученной в остановленной БД) копии БД. С этим файлом связана tablespace users, которая установлена для пользователя scott при его создании (здесь надо проверить этот факт и пересоздать пользователя scott с default tablespace users, если он был создан с другим по умолчанию табличным пространством).

На самом деле, в эксплуатируемых системах неизвестно заранее, какой файл «откажет», поэтому копируют всю базу целиком (все файлы БД).

Shutdown immediate

Далее средствами ОС Windows копируем все файлы в папку d:\cool_copy из папки d:\oracle\product\10.2.0\oradata\orcl на диск с наибольшим объемом свобод-

ной памяти. Еще раз запустим базу данных, чтобы затем выполнить в ней изменения. Здесь и далее при выполнении лабораторной работы, возможно, придется учитывать факт другого расположения home_directory Oracle. В этом случае указанные здесь пути необходимо скорректировать.

startup

Выполним новую транзакцию - добавим в таблицу scott.dept новую запись и зафиксируем ее.

insert into scott.dept values(1,'Publication','Moscow'); commit;

select * from scott.dept;

408

Теперь БД отличается от «холодной» копии, так как добавилась новая транзакция.

shutdown immediate

Сымитируем неисправность файлов с данными удалим USERS01.DBF

средствами ОС Windows из папки …:\oracle\product\10.2.0\oradata\orcl.

После «порчи» файла данных USERS01.DBF восстанавливаем его из «холодной» копии простым копированием из папки …:\cool_copy в папку

…:\oracle\product\10.2.0\oradata\orcl. Отметим, что мы скопировали файл, в кото-

ром нет новой строки в таблице dept пользователя scott.

Мы не стали здесь стартовать БД, чтобы не тратить время. Ясно, что при попытке старта нам будет выдано сообщение об отсутствии файла данных users01.dbf, после чего нам надо будет останавливать БД и копировать резервную копию файла Users01.dbf. Будем полагать, что мы прошли все эти стадии.

Вот теперь, после такого восстановления файла данных USERS01.DBF стартуем БД.

startup

База данных смонтирована, но не открыта. Oracle зарегистрировал расхождение в номере последней транзакции в файле данных из «холодной» копии и в управляющем файле БД, зарегистрировавшем последнюю транзакцию − добавление записи в scott.dept. Из-за этого расхождения Oracle требует восстановления базы данных.

Теперь «попросим» Oracle выполнить восстановление, что он и сделает с использованием информации из log файлов.

recover automatic database; alter database open;

select * from scott.dept;

Новая строка в таблице «dept», которой не могло быть в «холодной» копии users01.dbf, появилась из log файла повторным выполнением транзакции.

2. База данных находится в режиме archivelog (архивируется). Формируем «горячую» резервную копию файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.

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

shutdown immediate startup mount

409

Смонтировали базу данных для обеспечения возможности перевода ее в режим архивирования.

alter database archivelog;

Теперь откроем БД. alter database open;

Получим справку о режиме архивации archive log list;

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

Восстановим к первоначальному «эталонному» виду схему scott, т.е. удалим две таблицы, которые могли быть созданы при предыдущем выполнении этого раздела лабораторной работы.

drop table scott.tab1 cascade constraint; drop table scott.tab2 cascade constraint;

commit;

Теперь сформируем «горячую» копию файлa users01.dbf. Копию именно этого файла мы сделаем потому, что далее именно этот файл будет «испорчен» (на самом деле − удален), имитируя неисправность БД, требующую восстановления с использованием «горячей» (полученной в работающей БД) копии БД. С этим файлом связана tablespace users, которая установлена для пользователя scott при его создании.

Создадим директорию для хранения «горячей» копии users01.dbf.host MKDIR d:\g_copy − теперь сохраним состояние базы данных на диск

ALTER SYSTEM CHECKPOINT;

Начинается режим резервного копирования, который разрешается (begin backup) или запрещается (end backup) на уровне отдельного табличного пространства.

ALTER TABLESPACE USERS BEGIN BACKUP; $D:\oracle\product\10.2.0\db_1\BIN\OCOPY D:\oracle\product\10.2.0\oradata\orcl\USERS01.DBF d:\g_copy\USERS01.DBF

ALTER TABLESPACE USERS END BACKUP;

Выше приведенные строки написаны для Oracle 10g. Для Oracle 11g путь \oracle\product\10.2.0\db_1\bin\ надо заменить здесь и везде ниже по тексту на

%ORACLE_HOME%\bin.

Копия users01.dbf теперь в папке d:\g_copy. Выполним теперь в базе данных изменения: добавим таблицы scott.tab1(at1 number) и scott.tab2(at1 number), новую запись в таблицу scott.tab1 и зафиксируем (commit;) в БД это добавление.

create table scott.tab1(at1 number); create table scott.tab2(at1 number); insert into scott.tab1 values(1);

410

commit;

select * from scott.tab1;

Теперь БД отличается от «горячей» копии, так как добавились новые таблицы и новая запись, т.е. добавились новые транзакции. Остановим БД, чтобы внести неисправность в нее.

shutdown immediate

Сымитируем неисправность файлов с данными − удалим USERS01.DBF

средствами OC Windows из папки …:\oracle\product\10.2.0\oradata\orcl.

После порчи файла данных восстанавливаем его из «горячей» копии в папке «d:\g_copy» простым копированием. Отметим, что мы скопировали файл, в котором нет новых таблиц пользователя scott.Мы не стали здесь стартовать БД, чтобы не тратить время. Ясно, что при попытке старта нам будет выдано сообщение об отсутствии файла данных users01.dbf, после чего нам надо будет останавливать БД и копировать резервную копию файла Users01.dbf. Будем полагать, что мы прошли все эти стадии.

Вот теперь, после такого восстановления файла данных стартуем БД. startup

Oracle зарегистрировал расхождение в номере последней транзакции в файлах данных из «горячей» копии и в управляющем файле БД, зарегистрировавшем последнюю транзакцию − добавление таблиц в схеме scott. Поэтому база данных смонтирована, но не открыта. Теперь «попросим» Oracle выполнить восстановление, что он и сделает с использованием информации из log файлов.

recover automatic database; alter database open;

select * from scott.tab1;

Новая строка появилась при восстановлении из log файла повторным выполнением транзакции.

3. База данных находится в режиме archivelog (архивируется). Выполняется длинная транзакция, в ходе выполнения которой формируется несколько файлов журнализации. Затем происходит внезапная остановка базы данных (shutdown abort), после которой «теряются» незаархивированные оперативные файлы журнализации. Требуется восстановить базу данных с созданием новых файлов журнализации.

connect sys/sys as sysdba

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