CC BY-NC-ND
13
Д.А. Лысенко, В.В. Макаров, В.П. Челноков
АВТОМАТИЧЕСКОЕ РАСПОЗНАВАНИЕ И УПРАВЛЕНИЕ ПРОЦЕССАМИ ОПЕРАЦИОННОЙ СИСТЕМЫ
Большинство современных систем безопасности работают по одинаковому принципу распознавания нарушителей в системе: в каждой из подобных систем имеется специальная база данных с образцами сигнатур (уникальных последовательностей кодов) всех известных на текущий момент вирусов или база данных всех возможных сетевых атак. Для выявления потенциально опасных программ каждая запись из этой базы данных сравнивается с последовательностью машинных команд программы; ре ше ние о раз ре ше нии или зап ре те дос ту па при ни ма ет ся пос ле выполнения всех сравнений. Отсюда вытекают две основные проб ле мы:
1) необходимость регулярного обновления сигнатур;
2) работа постфактум.
Вместо статического анализа кода программы предлагается отс ле жи вать ди на ми ку ее ра бо ты и соз да вать ста тис ти чес кий портрет программы (СПП) с последующим выявлением некорре-к-тности ее выполнения. Достоинство такого способа - обнаружение вредоносного поведения прежде, чем оно окажет на систему какое-либо губительное воздействие, а также устранение этого воздействия (работа предфактум).
Если программа запущена, то она превращается в процесс операционной системы (ОС). Программа может порождать много процессов, но пока предлагаем исследовать программу, порождающую только один процесс.
ОС рас смот рим как обо лоч ку про цес са. Од нов ре мен но с об ра -ще ни ем про цес са к ка ко му-ли бо ре сур су вы пол ня ет ся сис тем ный вызов, т. е. процесс обращается к ОС. Таким образом, снимается ста тис ти ка об ра ще ний ис сле ду е мо го про цес са к ОС, по лу ча ем
СПП как цепочку системных вызовов.
Проведенный анализ СПП позволяет обнаружить в исследуемом процессе подозрительное поведение, указывающее на зараженность вирусом, а затем компенсировать подозрительное поведение так, чтобы не допустить сбоя в работе ОС.
Впервые предлагается новый подход к идентификации процессов с использованием статистического анализа совокупности выполняемых этим процессом системных вызовов. При этом все последовательности выполнения системных вызовов для разных процессов уникальны.
Рассмотрим получение СПП на основе анализа системных вызовов, в том числе пример журнала выполнения системных вызовов.
Пос та вим меж ду про цес са ми и ОС пос ред ник, ко то рый бу дет пе рех ва ты вать сис тем ные вы зо вы для каж до го про цес са по от -дельности и записывать результаты их выполнения в файл (журнал). Пример такого посредника - приложение strace в ОС LINUX. Фрагмент его журнала приведен на рис. 1.
20:33:44 access("/etc/ld.so.nohwcap", F_OK) = -1ENOENT (No such file or directory)
20:33:44open("/lib/tls/libc.so.6", O RDONLY) = 3
20:33:44 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\
260O\1"..., 512) = 512 20:33:44fstat64(3, (st_mode=SJFREG\0755, st_size=1270928,...}) = 0 20:33:44 mmap2(NULL, 1276892, PROT_READ\PROT_EXEC, MAP_
PRIVATE\MAP_DENYWRITE, 3, 0) = 0xb7ddc000 20:33:44 mmap2(0xb7f0a000,32768, PROT_READ\PROT_WRITE, MAP PRIVATE\MAP_FIXED\MAP_DENYWRITE, 3, 0x12e) = 0xb7f0a000 20:33:44 mmap2(0xb7f12000, 7132, PROT_READ\PROT_WRITE, MAP_
PRIVATE\MAP_FIXED\MAP_ANONYMOUS, -1, 0) = 0xb7f12000 20:33:44 close(3) = 0
Рис. 1. Фрагмент журнала системных вызовов
В этом журнале для каждого системного вызова могут указываться фактические параметры вызова, код результата его выполнения, время получения вызова, длительность его выполнения. Этот журнал будет простейшей версией СП П.
В качестве подобного посредника возможно применение и другого приложения, которое будет производить более сложный анализ перехватываемых системных вызовов. Главное ограничение на этот посредник - лимитирование времени его работы (т. е. посредник должен работать значительно быстрее самих системных вызовов).
При использовании данных журнала предлагается вначале разбить все системные функции ОС на группы, причем функции внутри каждой группы связаны по назначению. Например, функции создания и прекращения работы процессов объединяются в одну группу (fork, wait, exit).
Последующая нумерация системных функций (для их уникальной идентификации) производится следующим образом: сначала вы де ля ют ся подм но же ст ва не пе ре се ка ю щих ся но ме ров для каж дой груп пы функ ций, а за тем каж дой функ ции прис ва и ва ет ся собствен -ный уни каль ный но мер из со от ве т ству ю ще го ей подм но же ст ва.
Кроме того, выделяем так называемые парные функции, например: open и close, send и receive, wait и exit, открытие и закрытие семафора и т. д. Эти функции являются взаимнообратными по своему действию. Для таких функций предлагается выделять номера следующим образом: для одной функции - нормальный (положительный) номер, а для противоположной функции - противоположный по знаку номер. Например, для функции open - номер +1, а для функции close - номер -1. Тогда сумма влияния выполнения этих двух функций будет равна нулю, что будет указывать на парность этих функций.
Про иг но ри ро вав зна че ния фак ти чес ких па ра мет ров сис тем -ных вызовов, будем считать, что имя функции (т. е. ее уникальный номер) соответствует назначению системного вызова, а фак-ти чес кие па ра мет ры су ще ст вен но не бу дут ме нять наз на че ние этого вызова. Не будем также учитывать время работы самого сис тем но го вы зо ва, а бу дем от ме чать лишь вре мя его пос туп ле -ния. В даль ней шем пред по ла га ет ся до бав лять к сис тем но му вы -зову вес, пропорциональный времени его срабатывания.
Если системный вызов не срабатывает (его код ответа равен -1, что указывает на сбой при выполнении этого вызова), то выделяем эту ситуацию как нештатную и отмечаем вес этого вызова большим и отрицательным числом.
Некоторым системным функциям прикрепляем дополнительный вес, так как их назначение велико. К таким функциям отнесем su (вход в режим супервизора), fork (порождение процесса) и ряд других. Пусть этим системным вызовам соответствуют положительные выбросы на графиках.
Для рассмотрения видов СПП попробуем разобраться, как представлять информацию на основе данных журнала strace, чтобы уникально идентифицировать процесс. Кроме того, интересно выяснить из данных этого журнала, когда приложение превышает число используемых ресурсов.
Предлагаются три способа представления СПП: временной ряд, темповый ряд и граф.
СПП как временной ряд системных вызовов
Пе ред за пус ком про цес са ука жем, что жур нал сле ду ет по лу -чать для малых интервалов времени. Под малым интервалом времени будем понимать интервал, различающий разные времена поступления вызовов.
После получения данных журнала строим график. Для этого по оси OX откладываем время с выбранным интервалом, а по оси OY - номера вызываемых системных функций ОС. По существу журнал - это табличное представление временного ряда.
Каждому системному вызову будет соответствовать точка времен но го ря да, у ко то рой абс цис са рав на вре ме ни пос туп ле ния этого вызова, а ордината - номеру вызванной функции. На рис. 2 дан при мер вре мен ных ря дов для не ко то ро го про цес са.
■а <0
10
номера интервала
Рис. 2. Пример временного ряда (выполняются вызовы open, read, write, close; последняя точка имеет отрицательную ординату)
Очевидно, что временной ряд уникально идентифицирует про цесс.
В работе любой программы всегда можно выделить два существенно различающихся режима. После запуска программа сна ча ла вы пол ня ет про це ду ру ини ци а ли за ции (пе ре ход ный этап), а затем выходит на нормальный режим работы (рабочий этап). Поэтому временной ряд также состоит из двух частей -переходного и рабочего.
Как правило, переходный этап одинаков для разных запусков с разными входными параметрами одной и той же программы и, следовательно, для соответствующих временных рядов. Таким образом,переходный этап является инвариантом процесса. Именно по переходному этапу можно распознать этот процесс.
Переходный этап предлагается выделить следующим образом: получить несколько временных рядов при разных запусках одной программы с различных параметрами, а затем выделить одинаковую начальную составляющую во всех этих графиках.
Достоинства: простота генерации, сохранение корреляци-он ной за ви си мос ти меж ду вы зо ва ми, воз мож ность вы де ле ния пе ре ход но го эта па.
Недостатки: большой объем информации, что усложняет ее анализ.
СППкак темповый ряд системных вызовов
Перед запуском процесса укажем, что требуется получать журнал для больших интервалов времени. В этом случае на больших интервалах времени мы будем получать много сис тем ных вы зо вов, при чем к раз ным функ ци ям. В жур на ле указывается, в какой последовательности выполнялись эти системные вызовы, но мы в данном случае будем это игнорировать.
Строим темповый ряд для отдельно взятой функции: по оси ОХ откладываем время в соответствии с выбранным большим интервалом времени, а по оси ОУ - число системных вызовов к этой функции, выполненных в течение указанного интервала времени. Так можно получить темповые ряды для всех функций (рис. 3). Эти ряды называются темповыми, так как они де мо н стри ру ют ско рость из ме не ния пос туп ле ния вы зо вов.
180 160 140
т 120
§ 100
л
8 80
о
т 60 40 20 0
1 6 11 15 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106
секунды
Рис. 3. Пример темпового ряда функции
Можно совместить темповые графики для всех функций следующим образом: для этого достроим ось Z, перпендикулярную плоскости XY, на которую нанесем номера каждой функции. Затем для каждой функции перенесем ее график таким образом, чтобы начало графика (точка О) совпало с аппликатой номера этой функции; плоскость этого графика должна быть сопараллельна плоскости XY. Тогда все эти графики выстраиваются параллельно друг другу поперек оси Z и демонстрируют синхронное и совместное изменение темпа вызовов к разным функциям (рис. 4).
ФУНКЦИЯ 1
6000
2 5000
5 4000
3000
2000
1000
гИ'ггТтЧГ
1 7 13 19 25 31 37 43 48 55 61 67 73 79 85 91 97 103 109
секунды
ФУНКЦИЯ 2
6000
з 5000
4000
3000
1 7 13 19 25 31 37 43 48 55 61 67 73 79 85 91 97 103 109
секунды
ФУНКЦИЯ 3
6000
пттттттп
1 7 13 19 25 31 37 43 48 55 61 67 73 79 85 91 97 103 109
секунды
Рис. 4. Темповый ряд для разных функций
(1, 2, 3)
Какое преимущество дает темповый ряд? Он показывает периоды роста или снижения темпа вызовов той или иной функции. Если рассматривать ОС как объект, то темповый ряд представляет собой набор входов для этого объекта. Набор выходов - это темповый ряд использования ресурсов ОС для поддержки работы процесса (рис. 5).
систе:
темповый ряд использования системных ресурсов
Рис. 5. ОС как объект управления
Данный метод исследования работы ОС предложен сотрудником Института проблем управления РАН В.В. Макаровым. Темповый ряд системных вызовов - это набор неуправляемых входов ОС, темповый ряд использования системных ресурсов - это набор выходов ОС. Если в качестве посредника между процессом и ОС использовать регулятор, к входам которого подключить выходы ОС, то такой регулятор будет управлять работой ОС.
На рис. 6 приведен пример темпового ряда использования ре-сур сов ОС.
2 20
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85
секунды
Рис. 6. Пример темпового ряда использования ресурсов
Достоинства: простота генерации, большая сжатость информации по сравнению с временным рядом, демонстрация темпа поступления вызовов, возможность анализа ОС как объекта теории управления.
Недостатки: потеря корреляционной зависимости между отдельными вызовами, меньшая возможность выделения переходного этапа.
СППкак граф цепочки выполнения системных вызовов
Выполнение процесса можно описывать как направленный граф системных вызовов. В этом графе узлами являются номера системных функций, а направленные ребра последовательно соединяют между собой эти узлы, обозначая системные вызовы.
Конец направленного ребра указывает на ту функцию, к которой производится системный вызов, а начало этого ребра - на функцию, к которой был выполнен предыдущий системный вызов. Один из узлов является начальным. На ребре указывают число обращений к системной функции (вес ребра). Вес ребра показывает корреляцию между функциями, которые он соединяет.
Представление СПП в виде графа подробно описывает взаи-мос вя зи сис тем ных функ ций, од на ко оно дос та точ но слож но для автоматического анализа. Поэтому для автоматического преобразования выполняющегося процесса это представление надо привести к эквивалентному представлению в виде матриц смежности. На рис. 7 приведен фрагмент графа, на рис. 8 - соответствующая ему матрица смежности.
Рис. 7. Фрагмент графа системных вызовов
close rt sigaction write stat64 readlink getdents exit_group ioctl
close 0 1 0 1 0 2 1 1
rt sigaction 1 1 0 0 0 0 0 0
write 0 0 0 2 0 1 0 0
stat64 1 0 2 1 2 1 0 0
readlink 0 0 0 2 0 0 0 0
getdents 2 0 1 1 0 0 0 0
exit group 1 0 0 0 0 0 0 0
ioctl 1 0 0 0 0 0 0 1
Рис. 8. Матрица смежности графа сис тем ных вы зо вов
Достоинства: простота получения корреляции между функциями.
Недостатки: большой объем информации, усложняющий ее анализ.
Далее, говоря о предотвращении сбоев системы, предположим, что между процессами и ОС находится в качестве регулятора программа, которую назовем монитором безопасности (МБ). Эта программа перехватывает все системные вызовы и производит их статистический анализ. Если МБ обнаруживает в каком-либо процессе подозрительное поведение, указывающее на зараженность этого процесса вирусом, то МБ компенсирует это подозрительное поведение, тем самым пре до тв ра щая сбой ра бо ты сис те мы.
Представление работающего процесса как СПП (в том или ином из указанных выше видах) уникально идентифицирует процесс. Получив СПП, можно без вмешательства человека раз де лять про цес сы на безв ред ные и вре до нос ные, а так же идентифицировать пока не известные процессы, пополняя их базу данных. Модель, изображенная на рис. 5, впервые реали-зу ет прин цип под де рж ки бе зо пас но го функ ци о ни ро ва ния ОС под управлением МБ.
Литература
1. Макаров В.В., Носков С.А. Прототип монитора безопасности для
исследования новых принципов защиты систем // Третья международная конференция по проблемам управления. Пленарные доклады и избранные труды. М., 2006. С. 785-787.
2. Тюрин Ю.Н., Макаров А.А. Анализ данных на компьютере/Подред.
В.Э. Фигурнова. М.: ИНФРА-М, 2003.
3. Андропов А.М., Копытов Е.А., Гринглаз Л.Я. Теория вероятности и
математическая статистика. СПб.: Питер, 2004.
4. Ту Дж, Гонзалес Р. Принципы распознавания образов. М.: Мир, 1979.
5. Вапник В.Н., Червоненкис А.Я. Теория распознавания образов. Стат.
проблемы обучения. М.: Наука, 1974.
6. Касперский К. Компьютерные вирусы изнутри и снаружи. СПб.:
Пи тер, 2006.
