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

«read_stat» - производит чтение статуса процесса;

«read_open_file» - получение информации об открытых файлов процесса.



Рисунок 12 - структура разработанной СОА

7) “ser.c” - модуль сервера использующий больше для отладки или для консольного варианта. Основные его функции:

«get» - для вывода всех процессов клиента на консоль;

«run_comm_ser» - выполнение команд сервером;

8) “spisok.c” - модуль организующий работу над односвязным списком. Основные его функции:

«del_str» - удаление элемента списка;

«free_str» - освобождение памяти;

«delold_str» - удаление старых записей;

«cat_str» - добавление структуры;

«replace_str» - добавление только новых, старые записи обновляются;

9) “tools.c” - модуль содержит разнообразные сервисные функции:

«Writelog» - запись в журнал факта нарушения, в принятом формате;

«Sepch» - разбор строки по элементам;

«dependency_tcp_stat» - для сопоставления, процесс - соединение;

«strtobuf» - передача структур в файл или сокет;

«buftostr» - чтение из файла и инициализация соответствующих структур;

«fileto» - передача файла по сети;

«filein» - прием файла;

«modifs» - модификация строки.

В состав модели СОА также входят модули (form1.ui.h, form2.ui.h), которые относятся к серверу, а точнее к графической его части. Его функции (слоты) отвечают в основном за интерфейсную часть. Рассмотрим одну из ключевых:

«polit_get» - одна из самых важных функций. Производит анализ принятых данных от клиента, сравнивая их с соответствующим шаблоном безопасности. Производит уведомление, а также активное реагирование.

Также прилагается файл справки в HTML формате, сборки MakeFile.

2.5.5 Алгоритм функционирования модели обнаружения атак ЛВС

Алгоритм функционирования модели разработанной СОА ЛВС разбивается на два: алгоритм функционирования агента модели разработанной СОА, алгоритм функционирования менеджера модели разработанной СОА. Рассмотрим алгоритм функционирования агента СОА, блок-схема которого представлена на рис. 13. Первый блок переводит клиента в режим демона.

Демон (от английского demon или daemon - встречаются обе транскрипции) представляет собой программу выполняющуюся в фоновом режиме, незаметно для пользователя и дополняющую операционную систему каким либо специальным сервисом. Основная идея, положенная в основу демонов, состоит в том, что эта программа не вызывается пользователем в явной форме, а ожидает в памяти какого-либо определенного события. Инициатор генерации события может и не подозревать, что в оперативной памяти его ожидает демон (а иногда программа может выдать квитанцию о выполнении той или иной операции только в том случае, если она передала информацию соответствующему демону).

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

Четвертый блок проверяет завершение программы. Пятый приостанавливает бесконечный цикл на две секунды. Время задержки выбрано из результатов экспериментов, как оптимальное. На шестом блоке происходит подключение к серверу. Если это произошло, то седьмой блок циклически ждет команды от сервера. В случае ее поступления восьмой блок исполняет ее, образуя при этом программный поток. Это означает, что клиент не будет ждать пока ее выполнит, а параллельно будет ждать следующую команду. Такой подход обеспечивает повышенную производительность и стойкость, так как при сбое во время исполнения команды, клиент еще сможет отвечать на запросы. Появится возможность перезагрузить его.



Рисунок 13 - Блок-схема алгоритма функционирования клиента СОА

На рисунке 14 показана блок-схема алгоритма функционирования сервера СОА.

Рисунок 14 Блок-схема алгоритма функционирования сервера СОА

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

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

В блоке четыре происходит проверка условия завершения программы, если да то переход на блок пять, где закрываются все соединения, если нет то переход на блок шесть. Дальше следует основная часть, которая выполняется при автоматическом опросе клиентов. Программа имеет свыше двухсот функций и методов. По истечению задержки опроса в шестом блоке, которую можно всегда задать, происходит, на седьмом блоке, опрос тех клиентов, у которых стоит отметка: “снимать автоматически”, путем посылки соответствующей команды. Восьмой блок уменьшает счетчик опроса. После получения снимка процессов, на девятом блоке происходит анализ данных, путем сопоставления с шаблоном, отведенного каждому пользователю. При нарушении правила в десятом блоке, или при появлении нового процесса в зависимости от настройки соответствующей политики возможны варианты в одиннадцатом блоке: уведомление, означающее вывод сообщения о факте нарушения; сохранение, запись в журнал; активное реагирование, посылка команды (чаще всего завершить процесс) клиенту.

2.5.6 Оценка адекватности модели обнаружения атак ЛВС

На практике оценку адекватности модели производят несколькими способами:

1) сравнения результатов моделирования с экспериментальными результатами на реальном объекте;

2) использования других близких (аналогичных) моделей;

3) экспертные оценки.

В работе при проверке адекватности разработанной модели СОА использовался второй способ, а именно, полученные в результате моделирования (проведения натурных экспериментов) оценки показателей функционирования СОА (среднее время и вероятность обнаружения атак) были сравнены с аналогичными показателями наиболее известных СОА, таких как: «RealSecure», «OmniGuard Intruder Alert», «NetRanger», а также с расчетными значениями, определенными по формулам (1-6).

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

Формула для расчета среднего времени обнаружения атак:

(1)

где среднее время задержки - среднее время периода снимков множенное на два, так как после запроса всех клиентов с заданным интервалом времени, выдерживается такой же таймаут, чтобы получить соответствующие данные; среднее время потраченное сервером на анализ полученных данных, зависящее от производительности ПЭВМ и количества клиентов. В рассматриваемом случае занимает доли секунд.

(2)

где среднее время полупериода опроса клиентов;

(3)

где среднее время анализа данных от одного клиента;

Подставив выражения (2) и (3) формулу (1) получим:

(4)

Необходимо заметить, что для эффективного обнаружения атак должно выполняться условие:

(5)

Формула для расчета вероятности обнаружения атак:

(6)

где - предлагаемое требуемое время обнаружения атак (? 20 с).

Это означает, что среднее время периода снимков плюс время на их анализ, не должно превышать времени сбора данных агентом плюс задержки в канале связи. Время опроса определяется на сервере в зависимости от характеристик сети и производительности клиентов.

Результаты оценки показателей функционирования СОА (среднее время и вероятность обнаружения атак) по формулам (1-6) представлены в табл. 2-8.

Таблица 2 - Зависимость среднего времени и вероятности обнаружения атак от среднего времени запроса, при количестве клиентов К=10

tзапр	tобн	Робн
1	2.2	1
2	4.2	0.992
3	6.1	0.962
4	8.2	0.915
5	10.1	0.862
7	14.2	0.858
10	20.1	0.63
15	30.1	0.485
20	40.1	0.393

Таблица 3 - Зависимость среднего времени и вероятности обнаружения атак от среднего времени запроса, при количестве клиентов К=20

tзапр	tобн	Робн
1	2.2	1
2	4.2	0.991
3	6.2	0.96
4	8.2	0.913
5	10.5	0.859
7	14.3	0.753
10	20.3	0.627
15	30.3	0.483
20	40.3	0.391

Таблица 4 - Зависимость среднего времени и вероятности обнаружения атак от среднего времени запроса, при количестве клиентов К = 30

tзапр	tобн	Робн
1	2.3	1
2	4.3	0.99
3	6.3	0.958
4	8.3	0.91
5	10.3	0.857
7	14.2	0.755
10	20.2	0.628
15	30.2	0.484
20	40.2	0.392

Таблица 5 - Зависимость среднего времени и вероятности обнаружения атак от среднего времени запроса, при количестве клиентов К = 40

tзапр	tобн	Робн
1	2.4	1
2	4.4	0.989
3	6.4	0.956
4	8.4	0.908
5	10.4	0.854
7	14.4	0.751
10	20.4	0.625
15	30.4	0.482
20	40.4	0.39

Таблица 6 - Зависимость среднего времени и вероятности обнаружения от среднего времени запроса, при количестве клиентов К=50

tзапр	tобн	Робн
1	2.5	1
2	4.5	0.988
3	6.5	0.954
4	8.5	0.905
5	10.5	0.851
7	14.5	0.748
10	20.5	0.623
15	30.5	0.481
20	40.5	0.39

Расчеты проводились при tтреб = 20 с.

Из анализа табл. 2-6 видно, что с увеличением среднего времени запроса сервера клиентов увеличивается среднее время обнаружения атак, а значит, уменьшается вероятность их обнаружения, причем она уменьшается быстрее при увеличении количества клиентов в ЛВС. Оптимальным является среднее время запроса = 4 с, так как при этом при К=20 Робн = 0.915, т.е. удовлетворяет требованиям (? 20 с). При меньшем < 3 с, сервер не успевает собрать информацию о всех клиентах ЛВС, посылая при этом запрос и получая ответ от них.

Таблица 7 - Зависимость среднего времени анализа, обнаружения и вероятности обнаружения от количества клиентов при tзапр = 3 с.

К	tан	tобн	Робн
5	0.05	6.05	0.963
10	0.1	6.1	0.962
20	0.2	6.2	0.96
30	0.3	6.3	0.958
40	0.4	6.4	0.956
50	0.5	6.5	0.954
70	0.7	6.7	0.949
100	1	7	0.943
200	2	8	0.918
270	2.7	8.7	0.9

Таблица 8 - Зависимость среднего времени анализа, обнаружения и вероятности обнаружения от количества клиентов при tзапр = 4 с.

К	tан	tобн	Робн
5	0.05	8.05	0.917
10	0.1	8.1	0.915
20	0.2	8.2	0.913
30	0.3	8.3	0.908
40	0.4	8.4	0.906
50	0.5	8.5	0.905
70	0.7	8.7	0.9
75	0.75	8.75	0.898

Из анализа табл. 7, 8 видно, что с увеличением количества клиентов СОА средние времена анализа и обнаружения атак увеличиваются незначительно, но, уменьшается вероятность обнаружения атак, причем она уменьшается быстрее при увеличении среднего времени запросов - tзапр. Максимальным количеством клиентов при tзапр = 4 с является К= 70, так как при этом при tобн = 8.7 с Робн = 0.9, т.е. удовлетворяет требованиям (Робн_треб ? 0.9). При меньшем tзапр = 3 с является К= 270.

Таким образом, в результате сравнения показателей функционирования СОА, полученных при натурных испытаниях, с аналогичными показателями наиболее известных СОА и с расчетными значениями, представленными в табл. 2-8, показали, что разработанная СОА является адекватной выше рассмотренными оригинальными СОА.

Вывод

1) В данном разделе разработана и программно реализована новая модель (макет) СОА под ОС МСВС 3.0, являющаяся важнейшей компонентой комплексной системы защиты информации ЛВС военного назначения.

2) Проведены более 100 натурных испытаний разработанной модели при различных исходных данных, получены и обработаны количественные оценки показателей функционирования модели СОА по среднему времени и вероятности обнаружения атак.

3) Проведена оценка адекватности разработанной модели, которая позволила сделать вывод о ее адекватности.

3 РАЗРАБОТКА ПРЕДЛОЖЕНИЙ ПО ПРИМЕНЕНИЮ СИСТЕМЫ ОБНАРУЖЕНИЯ АТАК В ЛОКАЛЬНЫХ ВЫЧИСЛИТЕЛЬНЫХ СЕТЯХ ВОЕННОГО НАЗНАЧЕНИЯ И ОЦЕНКА ИХ ЭФФЕКТИВНОСТИ

3.1 Размещение системы обнаружения атак в ЛВС

На рисунке 14 отображен один из вариантов размещения агентов и менеджера модели СОА. Это классический способ размещения. В ЛВС штаба на всех или наиболее важных узлах (АРМ), устанавливается агенты. На АРМ администратора БИ (сервере) устанавливается менеджер. Он координирует работу клиентов, и централизованно управляет ими. На данном рисунке существует общий доступ в сеть связи общего пользования за счет применения криптомаршрутизатора, что повышает требования к защите информации к НСД. Во всей ЛВС всего один менеджер, но существуют варианты использования нескольких серверов. Соответственно при установке клиентской части, будет указан его IP адрес. На рисунке 14 клиенты отмечены информационным знаком, а сервер восклицательным. Также на всех АРМ установлено антивирусное ПО и средство разграничения доступа «SecretNet».

3.2 Использование системы обнаружения атак в коммутируемых сетях

На рисунке 15 представлен вариант использования СОА в коммутируемых сетях. Так как система работает на уровне приложения, то она независима от топологии сети. Для нее неважно в каком сегменте располагается серверная и клиентская часть. Необходимо только учесть временные задержки в сети и правильно настроить серверы БИ. В данном примере используется стек протоколов TCP/IP, при этом используются маршрутизаторы для разделения сетей, работающие на сетевом уровне.

3.3 Оценка эффективности предложений по применению системы обнаружения атак в ЛВС военного назначения

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

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



Рисунок 14 - Вариант размещения элементов системы обнаружения атак в ЛВС

Рисунок 15 - Вариант применения элементов СОА в коммутированных сетях

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

Под официальным понимается подход, при котором эффективность систем оценивается в соответствии с РД ФСТЭК по определенным показателям.

В работе использовался классический подход, т. е. оценка эффективности предложений по применению СОА в ЛВС проводилась по трем показателям, характеризующим функционирование СОА :

1) среднему времени обнаружения атак;

2) вероятности обнаружения атак;

3) экономическим затратам на аппаратную часть, на базе которой предполагается функционирование разработанной СОА. Расчетные соотношения представлены формулами (7-10) и результаты оценки представлены в табл. 9.

Эффективность предложений по применению СОА в ЛВС по вероятности обнаружения атак вычисляется по формуле:

(7)

где Pобн_изв - вероятность обнаружения атак уже известных систем; Pобн - вероятность обнаружения атак разработанной СОА.

Для расчета эффективности предложений по применению СОА в ЛВС по среднему времени обнаружения атак используется следующая формула:

(8)

где tобн - среднее время обнаружения атак разработанной СОА; tобн_изв - среднее время обнаружения атак существующих СОА.

Таблица 9 - Сравнение эффективности разработанной СОА с наиболее известными по вероятности обнаружения атак и по среднему времени обнаружения атак

№	Название СОА			Оценка эффективности по в %	Оценка эффективности по в%
1	OmniGuard Intruder Alert	15	0.85	59.33	11,7
2	RealSecure	8	0.95	23.75	1,3
3	NetRanger	10	0.9	39	6,5
4	Требуемая	20	0,9	69.5	6,5

Показатели разработанной СОА: Pобн = 0.962, tобн = 6.1 с.

В графической интерпретации результаты оценки эффективности предложений по применению разработанной СОА в ЛВС по сравнению с известными и эталонной приведены на рис. 16 - 17.



Рисунок 16 - Оценка эффективности предложений по применению разработанной СОА по сравнению с известными и эталонной по в %

атака система коммутируемая сеть

Рисунок 17 - Оценка эффективности предложений по применению разработанной СОА по сравнению с известными и эталонной по в %

Оценка экономической эффективности предложений по применению разработанной СОА проводилась по требованиям к стоимости аппаратной части. Минимальные требования к стоимости аппаратной части представлены в табл. 10.

Таблица 10 - Минимальные требования по стоимости сервера СОА к аппаратной части

№	Наименование	Цена в рублях
1	Материнская плата	1000
2	Центральный процессор (ЦП)	1500
3	Оперативная память (ОП)	800
4	Корпус (ATX)	700
5	Жесткий диск	1000
6	Устройства ввода	500
7	Монитор	2000
8	Сетевая карта	600
9	Видеокарта	400
Итого	8500

Таблица 11 - Минимальные требования по стоимости клиента СОА к аппаратной части

№	Наименование	Цена в рублях
1	Материнская плата	1000
2	Центральный процессор (ЦП)	1100
3	Оперативная память (ОП)	400
4	Корпус (ATX)	700
5	Жесткий диск	600
6	Устройства ввода	500
7	Монитор	1500
8	Сетевая карта	300
9	Видеокарта	400
Итого	6000

Общие эксплуатационные расходы разработанной модели СОА рассчитываются по формуле (8):

где: Eпэвм - общая стоимость ЭВМ, Eрз - расходы на эксплуатацию ЭВМ при решении задачи, руб/год; Eобсл - расходы на обслуживание при решении задачи, руб/год.

В расчетах не учитывались расходы на разработку, эксплуатацию, обслуживание ЭВМ при решении задачи.

Общая стоимость комплекта ПЭВМ, необходимого для функционирования СОА, вычисляется по формуле:

где N - количество серверов БИ, M - количество АРМ (клиентов); - стоимость сервера; - стоимость ПЭВМ; Кси_сп - коэффициент, учитывающий стоимость проведения специсследований и спецпроверок, (на настоящий момент времени Кси_сп =3..5).

Оценку экономической эффективности разрабатываемой модели СОА по требованиям к стоимости аппаратной части проведем для ЛВС, состоящей из 1 сервера, 20 клиентов по сравнению с требованиями известной СОА (RealSecurety) по формуле:

, (10)

где - общая стоимость комплекта ПЭВМ, необходимого для функционирования разработанной СОА; - общая стоимость комплекта ПЭВМ, необходимого для функционирования известной СОА.

Минимальная цена на одну ПЭВМ для сервера (Intel Pentium 3 1000 MГц, 128 MB RAM, HDD 40 Gb) составит 8500 рублей. Для клиента (Intel Pentium 2 233 MГц, 64 MB RAM, HDD 20 Gb), эта сума ровна 6000 руб.

.

Затраты по требованиям к аппаратной части, на базе которой функционирует СОА (RealSecurety) составляют 850000 руб, при таком же соотношении серверов и клиентов:

.

Тогда экономическая эффективность предложений по применению разработанной СОА по требованиям к стоимости аппаратной части по сравнению с требованиями известной СОА (RealSecurety) составляет .

.

Вывод

1) В разделе были разработаны предложения по применению системы обнаружения атак в локальных вычислительных сетях военного назначения, а именно, приведены варианты размещения системы обнаружения атак в ЛВС, а также в коммутированных сетях.

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

среднему времени обнаружения атак: 23.75 - 69.5 %;

вероятности обнаружения атак: 1.3 - 11.7 %;

экономическим затратам на аппаратную часть СОА: 24.4%.

Важными пунктами являются расчет адекватности и эффективности модели.

Заключение

1) Анализ руководящих документов, текущего состояния дел в области защиты информации, показал, что возможности традиционных средств и способов защиты информации в ЛВС не могут в полной мере обеспечить секретность, доступность и целостность информации в процессе ее обработки, хранения и передачи в ЛВС военного назначения.

2) Проведенный в работе анализ требований руководящих документов по защите информации показал, что для обеспечения эффективной защиты информации необходимо комплексное применение средств и систем защиты, в том числе систем обнаружения атак, сертифицированных версий которых под МСВС 3.0 в настоящее время нет.

3) В работе разработана модель нарушителя безопасности информации, а также рассмотрены возможные угрозы безопасности информации ЛВС, которые создают необходимость разработки системы обнаружения атак.

4) В работе разработана и программно реализована новая модель (макет) СОА под ОС МСВС 3.0, являющаяся важнейшей частью комплексной системы защиты информации ЛВС военного назначения. Проведена оценка разработанной модели, которая позволила сделать вывод о ее адекватности.

5) В работе разработаны предложения по применению системы обнаружения атак в ЛВС военного назначения, а именно, приведены варианты размещения системы обнаружения атак в ЛВС, а также в коммутированных сетях.

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

среднему времени обнаружения атак: 23.75 - 69.5 %;

вероятности обнаружения атак: 1.3 - 11.7 %;

экономическим затратам на аппаратную часть СОА: 24.4%.

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

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

Список используемых источников

1. Концепция защиты средств вычислительной техники (СВТ) и автоматизированных систем (АС) от несанкционированного доступа (НСД) к информации.- ГТК России, 30 марта 1992 года.

2. “UNIX” Разработка сетевых приложений. У.Р. Стивенс.

3. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации.- ГТК России, 30 марта 1992 года.

4. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.- ГТК России, 30 марта 1992 года.

5. Защита от несанкционированного доступа к информации. Термины и определения.- ГТК России, 30 марта 1992 года.

6. Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. ГТК России 1997 года.

7. В. А. Липатников, В. А. Малютин, Ю. И. Стародубцев. Информационная безопасность телекоммуникационных систем. СПб.: ВУС, 2002.-476с.

8. Технические описания аппаратуры защиты информации.

9. В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 2-е изд. - СПб.: Питер, 2003. - 864 с.

10. Соколов А. В., Степанюк О. М. Методы и средства защиты объектов и компьютерных сетей - М.: ООО «Фирма «Издательство АСТ», 2000. - 272 с.

11. Лукацкий А. В. Обнаружение атак. 2-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2003. - 608 с.

12. Зима В. М. Молдовян А. А., Молдовян Н. А. Безопасность глобальных сетевых технологий. 2-е изд. - СПб.: БХВ-Петербург, 2003. - 368 с.

13. Устройства для защиты объектов и информации./В.И.Андрианов, А.В.Соколов СПб.: ООО «Издательство Полигон», 2000.- 256 с.

ПРИЛОЖЕНИЯ

Приложение 1

Инструкция администратору по применению модели системы обнаружения атак

Системные требования.

О программе.

Установка сервера.

Установка клиента.

Работа с сервером.

Системные требования.

ОС: MCBC 3.0.

Сервер:

Pentium 3 1000 MГц; 12MB RAM, 32MB HDD;

Установленная библиотека QT 3.0 и выше.

Клиент: Pentium 2 233MГц; 64MB RAM, 8MB HDD.

О программе.

«Proc Read» - комплекс программ (клиент и сервер) предназначенных для обнаружения атак в ЛВС военного назначения. Возможности:

- передача статуса всех процессов в системе находящееся в /proc/pid/stat;

- передача информации о TCP соединениях;

- передача имен открытых файлов процессом;

- выполнение на клиентской машине любых команд поддерживающих командным интерпретатором;

- создания правил для процессов;

- информирования о новых процессов;

- автоматизированная работа.

Установка сервера.

Перед установкой убедитесь, что у вас стоит библиотека QT3 или выше.

Установка проходит в два этапа: компиляция и копирование исполняемого файла:

Переход в каталог «/procread»;

Компиляция модулей:

«Make serv»;

Компиляция сервера.

Переход в каталог «serv»;

Запуск скрипта «./compile»;

Переход в каталог «/procread»;

«make installs».

Установка клиента.

Переход в каталог «/procread»;

Занести в «cl.conf» IP адрес сервера;

«make main»;

«make installc».

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

Bourne shell (sh) «/etc/.profile»;

C shell (csh) «/etc/.login».

Для удаления программы:

«uninstalc» - клиента;

«uninstals» - сервера.

Работа с сервером.

Вкладка Клиенты. Ее экранная копия представлена на рисунке П 1.1.

На ней отображается зарегистрированные пользователи и их состояние, а также IP адрес пользователя, время отклика, количество снимков, новых процессов. В нижней части в поле ввода можно отправить команду пользователю, поддерживающая командным интерпретатором (Вначале ставить system, или специализированные).

Пример:

«system|killall nameprog»;

«|» - обязательный разделитель;

«get»получить снимок процессов.

Рисунок П 1.1 - Экранная копия вкладки «клиенты»

Пример:

«User1>get»;

«_packet_» пакетная обработка.

Пример:

«_packet_;system|killall nameprog1;system|killall nameprog2»;

«;» - обязательный разделитель для пакетной обработки.

Вкладка Процессы. Ее экранная копия представлена на рисунке П 1.2.

Отображает процессы в системе. Из нее можно завершить процесс или добавить в шаблон, для дальнейшего создания правила.

Вкладка Настройка клиентов. Ее экранная копия представлена на рисунке П 1.3. На данной странице следующие возможности:

- добавление пользователя (add client);

- удаление (del client);

Рисунок П 1.2 - Экранная копия вкладки «процессы»

- привязка шаблона;

- переименование клиента;

- установка сервера в автоматический режим сканирование (shoot process);

- просмотр журнала;

- отчистка журнала (clear all log);

- выставление времени отклика после истечении которого клиент будет считаться закрытым. (timeout).

Вкладка Настройка политик. Ее экранная копия представлена на рисунке П 1.4. На данной странице создаются правила для каждого процесса.

Action to new process - При появлении нового процесса клиенту будет передана соответствующая команда.

Рисунок П.1.3 - Экранная копия вкладки «настройка клиентов»

В формате команд могут присутствовать макросы:

«#» - замена PID процесса.

«$» - замена именем процесса.

«%» - замена длинным именем процесса.

Пример:

«system|killall $».

Сообщать о нарушении - в случае нарушения правила будет выдано сообщение.

«fname».

0 - правило игнорируется.

1 - При запуске данного процесса, в независимости от места нахождения.

Рисунок П.1.4 - Экранная копия вкладки «настройка политик»

«state».

пустая строка - правило игнорируется.

R - срабатывает если процесс находиться в состоянии run.

S - срабатывает если процесс находиться в состоянии sleep.

D - срабатывает если процесс находиться в состоянии sleep2.

Z - срабатывает если процесс находиться в состоянии zombi.

T - срабатывает если процесс находиться в состоянии debug.

Возможен набор значений.

«utime».

0 - правило игнорируется.

N - время в секундах которое разрешено процессу работать в режиме пользователя.

«Stime».

0 - правило игнорируется.

N - время в секундах которое разрешено процессу работать в режиме ядра.

«cutime».

0 - правило игнорируется.

N - время в секундах которое разрешено процессу и его потомкам работать в режиме пользователя.

«cstime»

0 - правило игнорируется.

N - время в секундах которое разрешено процессу и его потомкам работать в режиме ядра.

«priority».

0 - правило игнорируется.

N - при увеличение приоритета срабатывает данное правило.

«starttime».

0 - правило игнорируется.

N - время в секундах которое разрешено процессу работать.

«vsize».

0 - правило игнорируется.

N - максимальны разрешенный размер занимаемый виртуальной памяти в байтах.

«rss».

0 - правило игнорируется.

N - максимальны разрешенный размер занимаемый в реальной памяти.

«atcp».

0 - правило игнорируется.

N - разрешенное количество tcp соединений данному процессу.

«alnk».

0 - правило игнорируется.

N - разрешенное количество открытых символьных ссылок данному процессу.

«achr».

0 - правило игнорируется.

N - разрешенное количество открытых символьных устройств данному процессу.

«ablk».

0 - правило игнорируется.

N - разрешенное количество открытых блочных устройств данному процессу.

«asoc».

0 - правило игнорируется.

N - разрешенное количество открытых сокетов данному процессу.

«afif»

0 - правило игнорируется.

N - разрешенное количество открытых именованных каналов данному процессу.

«areg».

0 - правило игнорируется.

N - разрешенное количество открытых обычных файлов данному процессу.

«ano».

0 - правило игнорируется.

N - разрешенное количество открытых неизвестных по типу данному процессу.

На вкладке Option можно задать время периода снимков процессов клиентов, и проверка по шаблону правил.

Размещено на Allbest.ru