Анализ защищенной изолированной программной среды, основанной на технологии полной виртуализации на примере VMware Workstation Текст научной статьи по специальности «Компьютерные и информационные науки»

И.В. Шидловский-Москвин

АНАЛИЗ ЗАЩИЩЕННОЙ ИЗОЛИРОВАННОЙ

ПРОГРАММНОЙ СРЕДЫ, ОСНОВАННОЙ НА ТЕХНОЛОГИИ ПОЛНОЙ ВИРТУАЛИЗАЦИИ НА ПРИМЕРЕ VMWARE WORKSTATION

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

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

Однако многие специалисты переоценивают защищенность самих виртуальных машин (ВМ), а следовательно, построенных на их основе ИПС.

Ключевые слова: виртуализация, типы виртуализации, изолированная программная среда, WinDbg, VMware Workstation, Smartline DeviceLock, SSDT, перехват таблицы диспетчеризации системных сервисов.

В теоретической части данной статьи будет рассмотрена технология виртуализации, типы виртуализации и ИПС, построенные на базе полной виртуализации VMware Workstation, а также теоретическое обоснование возможности проникновения в ИПС. В качестве гостевой и хостовой ОС будет использоваться Microsoft Windows XP. В практической части будут представлено экспериментальное подтверждение описанного в теоретической части предположения. Будет описано два опыта. Первый опыт - изменение адресного пространства процесса гостевой ОС из хостовой на примере процесса

© Шидловский-Москвин И.В., 2010

Notepad.exe. Второй опыт - отключение средства контроля доступа пользователей к устройствам (Smartline DeviceLock) в гостевой ОС из хостовой. В заключение будут представлены полученные результаты работы и выводы.

Цели и задачи

Цель данной работы провести анализ защищенности изолированной программной среды, основанной на технологии виртуализации.

Для достижения поставленной цели необходимо решить следующие задачи:

- описать технологию виртуализации;

- сделать обзор известных типов виртуализации;

- описать способ построения ИПС, основанной на технологии виртуализации;

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

- предоставить экспериментальное подтверждение теоретических предположений.

Анализ использованных источников и литературы

При написании работы была использована литература по двум основным направлениям. Первое направление - труды по внутреннему устройству и архитектуре операционных систем. Сюда относятся книга Марка Руссиновича и Дэвида Соломона о внутреннем устройстве Windows, а также книги Эндрю Таненбаума. Второе направление - литература, описывающая технологию виртуализации. В силу доминирования коммерческих разработок в этой области сложно выделить источники, в которых наиболее полно описывается данная технология. Основная информация по данному вопросу была получена с официальных сайтов производителей.

Также следует отдельно выделить статью Ю.К. Сергеева «Использование технологии виртуализации для защиты информа-ции»1, описывающую идеологию данной работы. В этой статье Сергеев описывает создание механизма безопасности на базе технологии виртуализации и ОС с открытым кодом. Эта работа послужила толчком к написанию данной статьи, которая интересна прежде всего исследованием ОС с закрытым кодом и с использованием коммерческого (т. е. закрытого) продукта виртуализации.

Понятие виртуализации

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

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

Но все это было и раньше, почему же в последнее время так много заговорили о виртуализации? А случилось это потому, что за последние несколько лет был совершен большой технологический прорыв в области виртуализации ОС, открывший огромные возможности и перспективы. Под виртуализацией ОС понимают процесс создания на физическом компьютере так называемой виртуальной машины (ВМ) (что-то вроде виртуального компьютера), в которой устанавливается своя собственная ОС. Таких ВМ на одной физической платформе может быть несколько, при этом каждая ВМ имеет свои собственные виртуальные аппаратные компоненты: память, процессор, жесткий диск, сетевые адаптеры. Эти ресурсы резервируются ВМ за счет физических ресурсов аппаратного обеспечения компьютера. Такая модель организации вычислительных систем впервые появилась еще в 70-х гг. прошлого века в мэйнфреймах корпорации IBM System 360/370, когда требовалось сохранить предыдущие версии экземпляров ОС. Но лишь в XXI в. эта технология обрела новый смысл на серверных системах и настольных ПК.

Приложение Приложение

Операционная система

Аппаратное обеспечение

Рис. 1. Классическая архитектура компьютера

Приложение Приложение Приложение Приложение

Гостевая операционная система Гостевая операционная система

Виртуальное аппаратное обеспечение Виртуальное аппаратное обеспечение

Платформа виртуализации

Хостовая операционная система

Аппаратное обеспечение

Рис. 2. Один из видов виртуализации ОС

Под виртуализацией ОС будет пониматься следующее: в ОС физического компьютера (хостовой ОС) устанавливается платформа виртуализации (как обычная программа), с помощью которой создаются ВМ. На ВМ устанавливаются различные ОС (гостевые ОС). На рис. 1 и 2 показаны отличия классической архитектуры компьютера от архитектуры, содержащей ВМ.

Теоретическое обоснование опыта № 1

В данной статье будет рассмотрен пример программного продукта на базе технологии полной виртуализации VMware Workstation. Гипервизор находится между гостевой ОС и непосредственно оборудованием как слой абстрагирования. Этот слой абстрагирования позволяет любой ОС работать на аппаратных средствах, не имея информации о какой-либо другой гостевой ОС2.

VMware также виртуализирует в гипервизоре доступные устройства ввода/вывода и соответствующие драйверы для высокоэффективных устройств.

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

При запуске VMware Workstation 6.0 запускаются несколько процессов:

Имя процесса Назначение Владелец

vmnat.exe NAT SYSTEM

vmnetdhcp.exe DHCP SYSTEM

vmware.exe Control VMs user

vmware-authd.exe Authorization SYSTEM

vmware-tray.exe Taskbar user

vmware-vmx.exe Image VM user

Все процессы УМшаге, за исключением процесса ушшаге-vmx.exe, являются служебными. Сам же гипервизор и гостевая ОС находятся внутри адресного пространства процесса vmware-vmx.exe.

Рассмотрим схему, представленную на рис. 3, которая описывает принцип построения ИПС на базе технологии виртуализации.

Рис. 3. ИПС на базе виртуализации

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

Рассмотрим более подробно модель работы процессов ОС. Неважно, о какой ОС (в данном случае о гостевой или хостовой) идет речь. Все процессы в ОС выполняются в пользовательском пространстве. Только служебная информация о процессе - структура процесса, его идентификатор, список открытых дескрипторов и так далее (например, в ОС Windows структура EPROCESS) - находится в режиме ядра, и процесс не имеет к ней непосредственного доступа3.

Рис. 4. Адресное пространство процесса в ОС

Однако, как видно из рис. 4, любой модуль уровня ядра имеет полный доступ в адресное пространство процесса. Причем этот доступ не ограничен никакими правами (доступ распространяется на все подсистемы ОС: память, файловую систему, сетевую систему).

Теперь рассмотрим устройство процесса vmware-vmx.exe и его место в хостовой ОС более подробно.

Рис. 5. Адресное пространство процесса vmware-vmx.exe

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

Рис. 6. Изменение адресного пространства процесса гостевой ОС из хостовой

Рассмотрим данное предположение на примере редактирования текстового файла, т. е. изменения процесса гостевой ОС (notepad.exe) из хостовой ОС с помощью отладчика уровня ядра (WindDbg) -модуля ядра хостовой ОС.

Экспериментальная часть опыта № 1

Суть опыта: попытаться из хостовой ОС в гостевой ОС изменить текстовый документ в режиме реального времени.

Гостевая: С помощью редактора текста Notepad («Блокнот») создаем простой текстовый документ «Текстовый документ^хЬ» и впечатываем в него слово «hello».

Хостовая: При помощи WinDbg подключаемся к процессу vmware-vmx.exe и осуществляем поиск в виртуальной памяти по шаблону:

0:007> s -u 0x00000000 L?FFFFFFFF "hello"

2bb02340 0068 0065 006c 006c 006f 0440 0438 043c h.e.l.l.o.@.8.<.

Обнаружив адрес искомой строки, производим замену:

0:007> eu 2bb02340 "12"

Гостевая: В блокноте в режиме реального времени строка "hello" изменилась на "12llo".

Вывод: возможно получение полного доступа к пользовательскому процессу в гостевой ОС из хостовой.

Теоретическое обоснование опыта № 2

В опыте № 1 была показана возможность контроля приложения гостевой ОС из хостовой. Теперь продемонстрируем возможность контроля ядра гостевой ОС. Более того, - возможность отключения механизмов безопасности специализированного ПО в области защиты информации на примере средства контроля доступа пользователей к устройствам DeviceLock фирмы Smartline.

Вначале будет описан механизм диспетчеризации, используемый в ОС Windows. Затем будет приведен метод перехвата таблицы системных сервисов SSDT, используемый специализированным ПО по защите информации для обеспечения собственной безопасности. И в конце будет дана экспериментальная часть опыта.

Диспетчеризация системных сервисов

Диспетчеризация системных сервисов начинается с выполнения инструкции sysenter (для х86-процессоров Intel Pentium II и выше). Выполнение инструкции приводит к переключению в режим ядра и запуск диспетчера системных сервисов. Номер системного сервиса передается в регистре процессора EAX, а регистр EDX указывает на список аргументов, предоставленных вызвавшим кодом.

Диспетчеризация системных сервисов режима ядра

Как показано на рис. 7, ядро использует номер системного сервиса для поиска информации о нем в таблице диспетчеризации системных сервисов (system service dispatch table - SSDT). Каждый элемент этой таблицы содержит указатель на системный сервис4.

Пользовательский режим

Вызов системного сервиса

Диспетчер системных сервисов

SSDT

Режим ядра

Системный сервис 2

Рис. 7. Вызов системных сервисов

Диспетчер системных сервисов, KiSystemService, копирует аргументы вызвавшего кода из стека потока пользовательского режима в свой стек режима ядра (поэтому вызвавший код не может изменить значения аргументов после того, как они переданы ядру) и выполняет системный сервис.

Инструкции для диспетчеризации сервисов исполнительной системы Windows содержатся в системной библиотеке Ntdll.dll. DLL-модули подсистем окружения вызывают функции из Ntdll.dll для реализации своих документированных функций.

Функции Windows API ядра

Windows-приложение

NtWriteFile в Ntdll.dll

WriteFile в Kernel32.dll

Вызов WriteFileO Возврат управления

Вызов NtWriteFlleO Возврат управления

Вызов инструкции sysenter Возврат управления

Пользовательский режим

Программное прерывание

Режим ядра

KiSystemService в Ntoskrnl.exe

NtWriteFile в Ntoskrnl.exe

Вызов NtWriteFileO Закрытие прерывания

Выполнение операции Возврат управления

Рис. 8. Диспетчеризация системных сервисов

Как показано на рис. 8, Windows-функция WriteFile в Kernel32.dll вызывает функцию NtWriteFile из Ntdll.dll. Она, в свою очередь, выполняет соответствующую инструкцию (sysenter), вызывающую срабатывание ловушки системного сервиса и передающую номер системного сервиса NtWriteFile. Далее диспетчер системных сервисов (функция KiSystemService в Ntoskrnl.exe) вызывает истинную NtWriteFile для обработки запроса на ввод-вывод.

Перехват таблицы системных сервисов

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

На рис. 9 представлен перехват таблицы SSDT программным средством контроля доступа DeviceLock.

Перехват ОепсеЬоск-ои

| Реу1се1_оскРмуегЩрЕх1СЗ+0х1182 |

| №5е1Уа1иеК"ёу~|<—

Рис. 9. Перехват DeviceLock-ом системного сервиса NtSetValueKey

Экспериментальная часть опыта № 2 Отключение DeviceLock-а на гостевой ОС

Суть опыта: попытаться из хостовой ОС перехватить системные сервисы таблицы 88БТ гостевой ОС и восстановить в ней сервисы, «замененные» DeviceLock-ом на свои. Таким образом, будет осуществлено отключение механизма безопасности (контроль доступа) гостевой ОС из хостовой.

Гостевая:

Устанавливаем DeviceLock. В табл. 1 представлен список перехваченных им системных сервисов, полученный с помощью Иоо1к^ ИпЬоокег.

Таблица 1

Системные сервисы SSDT, перехваченные DeviceLock-ом (Rootkit Unhooker)

Id Service Name Hooked Address (old) Address

41 NtCreateKey Yes 0x8061A286 0xF79F60DE

63 NtDeleteKey Yes 0x8061A716 0xF79F615E

65 NtDeleteValueKey Yes 0x8061A8E6 0xF79F61C4

108 NtMapViewOfSection Yes 0x805A7480 0xF79F62AE

119 NtOpenKey Yes 0x8061B658 0xF79F612A

122 NtOpenProcess Yes 0x805C1296 0xF79F6278

128 NtOpenThread Yes 0x805C1522 0xF79F6242

247 NtSetValueKey Yes 0x8061880C 0xF79F6182

257 NtTerminateProcess Yes 0x805C8C2A 0xF79F61EE

258 NtTerminateThread Yes 0x805C8E24 0xF79F6218

Имя модуля-перехватчика - C:\WINDOWS\system32\driv-ers\DeviceLockDriverHlpExtG3.SYS.

Также в таблице представлены исходные адреса оригинальных сервисов. Гостевая:

Запускаем WinDbg в режиме отладчика ядра (Kernel Debug) на локальной машине (Local).

Отображаем адрес таблицы системных сервисов (SSDT). lkd> dd kiservicetable

80501b8c 80599948 805e6db6 805ea5fc 805e6de8 80501b9c 805ea636 805e6e1e 805ea67a 805ea6be 80501bac 8060bdfe 8060cb50 805e21b4 805e1e0c 80501bbc 805cade6 805cad96 8060c424 805ab5ae 80501bcc 8060ba3c 8059ddbe 805a5a00 805cc8c4 80501bdc 804ff828 8060cb42 8056bcd6 8053500e 80501bec 806050d4 805b1c3a 805eab36 80619e56 80501bfc 805ef028 8059a036 8061a0aa 805998e8

Например, 80599948 - адреса 1-го системного сервиса. В окне Memory выводим на экран содержимое nt!kiservicetable (в удобочитаемом виде Pointer and Symbol) и видим, что это nt!NtAcceptConnectPort

80501b8c 80599948 nt!NtAcceptConnectPort 80501b90 805e6db6 nt!NtAccessCheck 80501b94 805ea5fc nt!NtAccessCheckAndAuditAlarm Просмотрев весь список SSDT, выбираем адреса таблицы, указывающие на те системные сервисы, которые подменил DeviceLock (список 1):

1) 80501c30 f79f60de DeviceLockDriverHlpExtG3+0x10de

2) 80501c88 f79f615e DeviceLockDriverHlpExtG3+0x115e

3) 80501c90 f79f61c4 DeviceLockDriverHlpExtG3+0x11c4

4) 80501d3c f79f62ae DeviceLockDriverHlpExtG3+0x12ae

5) 80501d68 f79f612a DeviceLockDriverHlpExtG3+0x112a

6) 80501d74 f79f6278 DeviceLockDriverHlpExtG3+0x1278

7) 80501d8c f79f6242 DeviceLockDriverHlpExtG3+0x1242

8) 80501f68 f79f6182 DeviceLockDriverHlpExtG3+0x1182

9) 80501f90 f79f61ee DeviceLockDriverHlpExtG3+0x11ee 10) 80501f94 f79f6218 DeviceLockDriverHlpExtG3+0x1218

Список 1. Фрагмент таблицы SSDT после установки DeviceLock-а. Хостовая:

Структура таблицы диспетчеризации системных сервисов идентична для ОС одной версии. Система на гостевой и хостовой ОС в нашем эксперименте одна и та же - Windows XP. Поэтому, для того чтобы понять, какие именно системные сервисы перехватил DeviceLock, запускаем WinDbg на хостовой системе и получаем их список.

Таблица 2

Название и номера оригинальных сервисов, перехваченные DeviceLock-ом

№ п/п № в SSDT Название системного сервиса

1 41 NtCreateKey

2 63 NtDeleteKey

3 65 NtDeleteValueKey

4 108 NtMapViewOfSection

5 119 NtOpenKey

6 122 NtOpenProcess

7 128 NtOpenThread

8 247 NtSetValueKey

9 257 NtTerminateProcess

10 258 NtTerminateThread

В адресном пространстве процесса vmware-vmx.exe найдем SSDT-таблицу гостевой системы (т. е в адресном пространстве хостовой ОС найдем адрес SSDT-таблицы гостевой ОС).

Прикрепляемся к процессу vmware-vmx.exe и по шаблону (адрес первого системного сервиса в SSDT-таблице гостевой ОС = = 80599948) ищем саму таблицу диспетчеризации:

0:007> s -d 0x00000000 L?FFFFFFFF 80599948 0c981b8c 80599948 805e6db6 805ea5fc 805e6de8 H.Y..mA..A.mA. Таким образом, нашли адрес в SSDT-таблице гостевой ОС в адресном пространстве процесса VMware-vmx.exe (т. е. в адресном пространстве хостовой ОС).

Отобразим адреса, начиная с 0c981b8c, предположительно - это начало SSDT

0:007> dd 0c981b8c

0c981b8c 80599948 805e6db6 805ea5fc 805e6de8 0e2c1b9c 805ea636 805e6e1e 805ea67a 805ea6be 0e2c1bac 8060bdfe 8060cb50 805e21b4 805e1e0c 0e2c1bbc 805cade6 805cad96 8060c424 805ab5ae 0e2c1bcc 8060ba3c 8059ddbe 805a5a00 805cc8c4 0e2c1bdc 804ff828 8060cb42 8056bcd6 8053500e 0e2c1bec 806050d4 805b1c3a 805eab36 80619e56 0e2c1bfc 805ef028 8059a036 8061a0aa 805998e8

Гостевая:

lkd> dd kiservicetable

80501b8c 80599948 805e6db6 805ea5fc 805e6de8 80501b9c 805ea636 805e6e1e 805ea67a 805ea6be 80501bac 8060bdfe 8060cb50 805e21b4 805e1e0c 80501bbc 805cade6 805cad96 8060c424 805ab5ae 80501bcc 8060ba3c 8059ddbe 805a5a00 805cc8c4 80501bdc 804ff828 8060cb42 8056bcd6 8053500e 80501bec 806050d4 805b1c3a 805eab36 80619e56 80501bfc 805ef028 8059a036 8061a0aa 805998e8

Таблица диспетчеризации системных сервисов гостевой ОС найдена.

Теперь восстановим в таблице адреса оригинальных системных сервисов, перехваченных DeviceLock-ом. Хостовая:

Известно, что DeviceLock перехватывает 247 сервис-таблиц NtSetValueKey (см. табл. 1). Проверим, что лежит по адресу

0:007> dd 0c981b8c+(f7*4) 0c981f68 f796e182 80571406 80609092 80522c50 Действительно, там лежит адрес функции DeviceLock-а вместо оригинального системного сервиса (см. Список 1, номер 8):

8) 80501f68 f79f6182 DeviceLockDriverHlpExtG3+0x1182 Гостевая:

Выясним адрес оригинального системного сервиса:

lkd> dd nt!ntsetvaluekey

8061880c 58685c6a e8804dfe fff1f6f8 8966f633

Хостовая:

Восстановим адрес оригинального системного сервиса гостевой ОС из хостовой:

0:007> ed 0c981f68 0x8061880c

Гостевая:

Убедимся, что оригинальный системный сервис восстановлен: 80501f68 8061880c nt!NtSetValueKey

Аналогичным образом восстанавливаем остальные 9 адресов оригинальных сервисов в таблице диспетчеризации гостевой ОС из хостовой.

После восстановления всех перехваченных системных сервисов таблица SSDT выглядит следующим образом.

Таблица 3

Таблица SSDT после восстановления адресов оригинальных сервисов

и Service Name Hooked Address

41 NtCreateKey --- 0х8061А286

63 NtDeleteKey --- 0х8061А716

65 NtDeleteValueKey --- 0х8061А8Е6

108 NtMapViewOfSection --- 0х805А7480

119 NtOpenKey --- 0х8061В658

122 NtOpenProcess --- 0х805С1296

128 NtOpenThread --- 0х805С1522

247 NtSetValueKey --- 0х8061880С

257 NtTerminateProcess --- 0х805С8С2А

258 NtTerminateThread --- 0х805С8Е24

Вывод: Возможно получение полного контроля над таблицей системных сервисов SSDT в гостевой ОС из хостовой.

Заключение

В результате проведенного исследования были решены поставленные задачи и получены следующие основные результаты:

- описана технология виртуализации;

- сделан обзор известных типов виртуализации;

- описан способ построения ИПС, основанной на технологии виртуализации;

- дано теоретическое обоснование возможности полного доступа в изолированную программную среду, построенную на базе полной виртуализации извне;

- предоставлено в двух опытах экспериментальное подтверждение теоретических предположений.

На основе полученных результатов были сделаны следующие выводы.

Вывод 1: Возможно получение полного доступа к пользовательскому процессу в гостевой ОС из хостовой.

Вывод 2: Возможно получение полного контроля над таблицей системных сервисов SSDT в гостевой ОС из хостовой.

Примечания

Сергеев Ю.К. Использование технологий виртуализации для защиты информации // Вестник РГГУ. 2009. № 10. Сер. «Информатика. Защита информации. Математика». С. 98-109.

См.: Материалы сайта производителя VMware Workstation [Электронный ресурс] // Сайт VMware. [М., 2009]. URL: http://www.vm ware. com/ru/ (дата обращения: 4.11.2009).

См.: Таненбаум Э. Современные операционные системы. 2-е изд. СПб.: Питер, 2006.

См.: Руссинович M, Соломон Д. Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мастер-класс. М.: Русская редакция; СПб.: Питер, 2006.

Там же; см. также: Холлунг Г., Батлер Дж. Руткиты: внедрение в ядро Windows. СПб.: Питер, 2007.

1

2

3

4

5