(2.20)

где Xk принимает значения при k =2, 3, …, N. Если k=1, то .

Теперь можно найти оптимальное решение - оптимальные приросты вычислительных мощностей и сами мощности комплексов. Здесь на k-ом шаге ищется минимум по Xk при фиксированном , причем параметр может принимать значения

.

Пример численного расчета

Имеется программно-аппаратный комплекс обнаружения компьютерных атак, вычислительная мощность которого вследствие роста трафика составляет 20% от необходимой. Увеличение мощности до 100% может быть достигнуто как за счет реконструкции действующего комплекса, так и за счет введения трех новых (возложения функций обнаружения атак на три имеющихся в сети рабочих станции с сохранением их основной функции в сети).

Укажем границы вычислительных мощностей. Здесь и далее метрика вычислительной мощности комплекса будет выражаться в процентах от вычислительной мощности рабочей станции:

,

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

Таблица 2.6

х	0 %	10 %	20 %	30 %	40 %	50 %	60 %	70 %	80 %	90 %	100 %
Ф1(Х1)	0	10	15
Ф2(Х2)	0	0	15	20	25	30	35
Ф3(Х3)	0	20	25	30	35	40
Ф4(Х4)	0	5	10	15

Затраты на прирост вычислительных мощностей комплексов приведены в табл. 2.7. Здесь учтено, что суммарный прирост вычислительных мощностей по всем комплексам равен 80%. Первая, третья и четвертая строки табл. 2.6 и 2.7 совпадают, а вторая строка табл. 2.7 получается из второй строки табл. 2.6

Таблица 2.7

	Прирост вычислительных мощностей, %
х	0	10	20	30	40	50	60	70	80
ц1(Х1)	0	10	15
ц2(Х2)	0	5	10	15	20
ц3(Х3)	0	20	25	30	35	40
ц4(Х4)	0	5	10	15

Переходим к вычислению значений функции . Учтем, что она определена только для . Таблица значений и не приводится, так как она по существу содержится в табл. 2.7. Далее вычисляем значения и . Для этого составляем табл. 2.8. Числа для фиксированного расположены на прямой, параллельной диагонали, идущей слева снизу вверх направо, и наименьшее среди них есть . Учитываем, что параметр на этом этапе может изменяться лишь от 0 до 60, так как суммарный прирост мощностей на первых двух комплексах не может быть более 60. Значения и приведены в табл. 2.9.

Таблица 2.8

-X2	X2	0	10	20	30	40	50	60	70	80
	2(X2)	0	5	10	15	20
	F1(-X2)
0	0	0	5	10	15	20
10	10	10	15	20	25	30
20	15	15	20	25	30	35
30
…
80

Таблица 2.9

	0	10	20	30	40	50	60	70	80
	0	5	10	15	20	30	35
	0	10	20	30	40	30	40

Далее составляем таблицу 2.10 значений . При этом учитываем, что функция определена только при значениях аргумента от 0 до 60. Значения и приведены в таблице 2.11.

Наконец, составляем табл. 2.12, чтобы определить для единственного значения аргумента =80. Получаем , притом . Руководствуясь известными правилами , из табл. 6 находим

,

а по табл. 4 определяем ,

после чего получаем .

Таблица 2.10

-X3	X3	0	10	20	30	40	50	60	70	80
	3(X3)	0	20	25	30	35	40
	F2(-X3)
0	0	0	20	25	30	35	40
10	5	5	25	30	35	40	45
20	10	10	30	35	40	45	50
30	15	15	35	40	45	50	55
40	20	20	40	45	50	55
50	30	30	50	55	60
60	35	35	55	60

несанкционированный воздействие информационный защита

Таблица 2.11

	0	10	20	30	40	50	60	70	80
	0	5	10	15	20	30	35	50	55
	0	0	0	0	0	10	0	30	40

Таблица 2.12

-X4	X4	0	10	20	30	40	50	60	70	80
	4(X4)	0	5	10	15
	F3(-X4)
0	0
10	5
20	10
30	15
40	20
50	30				45
60	35			45
70	50		55
80	55	55

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

Итак, мощность действующего комплекса следует довести до максимальной величины 60%, третий комплекс не организовывать, а первый и четвертый комплексы организовать мощностью по 20%.

Выводы по разделу

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

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

3. Разработка макета программного комплекса защиты автоматизированных систем от несанкционированных воздействий

3.1 Разработка алгоритмов функционирования программного комплекса защиты автоматизированных систем от несанкционированных воздействий

Деструктивные возможности удаленных атак и вредоносных программ связаны с тем, что большинство из них напрямую нацелены на слабые места средств защиты, уязвимости операционных систем и системных приложений [5], составляющих материальную основу узлов АС. Высокая пропускная способность современных СПД значительно расширяет деструктивные возможности удаленных атак, что создает условия для пропуска несанкционированных воздействий и, как следствие, для деструктивных воздействий на АС [6], что, в свою очередь, приводит к снижению их устойчивости.

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

Гарантированно решить задачу своевременного предоставления вычислительных ресурсов можно за счет временного блокирования некоторых целевых функций АС. Целевыми функциями АС являются обработка запросов на обслуживание от санкционированных абонентов и выполнение расчетных задач. Существующие технические решения не позволяют достичь указанных целей в автоматическом режиме и требуют вмешательства обслуживающего персонала.

Такая коррекция структуры и параметров объекта полностью соответствует представлениям о принципах управления АС как сложной развивающейся системой [22].

Поиск эффективных технических решений повышения устойчивости функционирования АС в условиях несанкционированных воздействий может быть осуществлен, как показано на рис. 2.19, путем повышения эффективности функционирования системы защиты, которого можно достичь за счет повышения достоверности обнаружения (распознавания) несанкционированных воздействий путем расширения признакового пространства системы защиты и за счет управления вычислительными ресурсами АС, которое осуществляется путем коррекции параметров системы защиты и структуры АС [28]. Значение показателей эффективности системы защиты выбирают в зависимости от требуемой достоверности и своевременности обнаружения несанкционированных соединений и с учетом пропускной способности СПД, а также в зависимости от подверженности изменениям отношений объектов и субъектов доступа защищаемой АС. Критерием необходимости принятия решения на управление вычислительными ресурсами является значение отношения количества зарегистрированных несанкционированных ИП к общему количеству временно заблокированных и неактуальных ИП.

Блок-схема алгоритма системы защиты АС, повышающего ее устойчивость в условиях несанкционированных воздействий, представлена на рис. 3.4. В блок-схеме приняты следующие обозначения:

Zоп - Первоначальный уровень коэффициента актуальности всех опорных идентификаторов;

IDпр - идентификатор принятого пакета сообщений;

IDоп - опорный идентификатор санкционированного ИП;

{IDоп} - совокупность опорных идентификаторов санкционированных ИП;

Zj - коэффициент актуальности j-го опорного идентификатора санкционированного ИП;

IDнеакт - неактуальный идентификатор санкционированного ИП;

{IDнеакт} - совокупность неактуальных идентификаторов санкционированных ИП;

IDнс - идентификатор несанкционированного ИП;

IDбл - идентификатор временно заблокированного санкционированного ИП;

{IDбл} - совокупность идентификаторов временно заблокированных санкционированных ИП;

{IDнс} - совокупность запомненных идентификаторов несанкционированных ИП;

IPпр - адрес инициатора несанкционированного ИП (адрес принятого пакета сообщений);

{IPоп} - совокупность адресов инициаторов ИП находящихся в списке опорных идентификаторов;

{IPнеакт} - совокупность адресов инициаторов ИП находящихся в списке опорных идентификаторов;

Mпр - наименование процесса инициировавшего несанкционированный ИП;

{Mоп} - множество наименований санкционированных процессов.



Рис. 3.4 Блок-схема алгоритма системы защиты АС повышающего ее устойчивость в условиях несанкционированных воздействий



Рис. 3.4 Блок-схема алгоритма системы защиты АС, повышающего ее устойчивость в условиях несанкционированных воздействий (окончание)

Решение задачи повышения устойчивости АС в условиях несанкционированных воздействий декомпозируется на совокупность следующих действий [21]. Предварительно задают (см. блок 1) массив из N1 опорных идентификаторов санкционированных ИП, в качестве которых принимают идентификационные признаки ИП, содержащие адреса и номера портов отправителя и получателя пакетов, и запоминают их. Задают массивы для хранения Q?1 неактуальных идентификаторов санкционированных ИП, P?1 идентификаторов несанкционированных ИП и X?1 временно заблокированных идентификаторов, а также задают M?1 наименований санкционированных процессов. Кроме того, задают максимально допустимое число Кmax появлений любого из принимаемых несанкционированных ИП и устанавливают первоначальный уровень ZОП коэффициента актуальности для всех опорных идентификаторов. Устанавливают первоначальное количество Ki появлений i-го несанкционированного ИП равным нулю, где i=1,2,3...P. Кроме того, устанавливают равными нулю начальные значения количества идентификаторов Q, P и X.

Из канала связи принимают (см. блок 2) k-ый пакет сообщения, где k=1,2,3… и выделяют (см. блок 3) из заголовка принятого пакета идентификационные признаки, в качестве которых рассматривают идентификатор ИП. Затем сравнивают (см. блок 4) выделенный идентификатор с опорными на предмет совпадения. Совпадение при этой проверке означает, что принятый пакет сообщений относится к санкционированному ИП. Далее корректируют коэффициенты актуальности опорных идентификаторов, для чего уменьшают (см. блок 5) на единицу коэффициенты актуальности, принадлежащие всем опорным идентификаторам кроме совпавшего с выделенным из принятого пакета сообщений. Под коэффициентами актуальности опорных идентификаторов понимают показатель, характеризующий относительную частоту появления пакета сообщений с идентификационными признаками, совпадающими с опорным идентификатором, в канале связи. Использование этого показателя обусловлено необходимостью сокращения времени, затрачиваемого на анализ каждого пакета сообщений. Затем корректируют (см. блок 7) массивы опорных и неактуальных идентификаторов в соответствии с коэффициентами актуальности опорных идентификаторов, для чего запоминают дополнительно опорные идентификаторы, коэффициент актуальности которых Zj равен нулю, в массив неактуальных идентификаторов. Удаляют опорные идентификаторы, коэффициент актуальности которых Zj равен нулю из массива опорных идентификаторов. Количество неактуальных идентификаторов Q увеличивают на количество опорных идентификаторов, перемещенных в массив неактуальных идентификаторов. После этого принимают (см. блок 8) очередной пакет сообщений и повторяют действия по сравнению его идентификатора с опорными.

В случае отсутствия совпадения идентификатора принятого пакета сообщений с предварительно запомненными опорными идентификаторами корректируют коэффициенты актуальности опорных идентификаторов, для чего коэффициенты актуальности всех опорных идентификаторов уменьшают на единицу (см. блок 9). Корректируют (см. блок 11) массивы опорных и неактуальных идентификаторов в соответствии с коэффициентами актуальности опорных идентификаторов, для чего запоминают дополнительно опорные идентификаторы, коэффициент актуальности которых Zj равен нулю, в массив неактуальных идентификаторов. Удаляют опорные идентификаторы, коэффициент актуальности которых Zj равен нулю из массива опорных идентификаторов. Количество неактуальных идентификаторов Q увеличивают на количество опорных идентификаторов, перемещенных в массив неактуальных идентификаторов.

Затем дополнительно сравнивают (см. блок 12) идентификатор принятого пакета сообщений с идентификаторами, записанными в массив неактуальных идентификаторов.

В случае совпадения дополняют (см. блок 13) массив опорных идентификаторов, для чего идентификатор, совпавший с идентификатором принятого пакета сообщений, удаляют из массива неактуальных идентификаторов, запоминают его в массив опорных идентификаторов и устанавливают (см. блок 14) для него коэффициент актуальности Zj равный ZОП. Количество неактуальных идентификаторов Q уменьшают на единицу. После этого принимают (см. блок 8) очередной пакет сообщений и повторяют действия по сравнению его идентификатора с опорными и неактуальными идентификаторами.

При отсутствии совпадения (см. блок 16) дополнительно сравнивают идентификатор принятого пакета сообщений с ранее запомненным идентификатором i-го несанкционированного ИП. При их совпадении (см. блок 23) число его появлений Ki увеличивают на единицу. В случае отсутствия совпадения (см. блок 17) корректируют массивы опорных и временно заблокированных идентификаторов, для чего увеличивают на единицу количество идентификаторов несанкционированных ИП P и сравнивают (см. блок 18) его с общим количеством временно заблокированных и неактуальных идентификаторов Q и X. Результат этого сравнения - критерий необходимости принятия решения на управление вычислительными ресурсами, который является значением отношения количества зарегистрированных несанкционированных ИП к общему количеству временно заблокированных и неактуальных ИП. При выполнении условия P>(Q+X), удаляют из массива опорных идентификаторов один опорный идентификатор с наименьшим коэффициентом актуальности и запоминают его в массив временно заблокированных идентификаторов (см. блок 19). Количество временно заблокированных идентификаторов X увеличивают на единицу. Затем корректируют (см. блок 21) массив несанкционированных идентификаторов, для чего запоминают идентификатор принятого пакета сообщений в массив несанкционированных идентификаторов, присваивают ему очередной (i+1)-ый идентификационный номер и число его появлений Ki+1 увеличивают на единицу.

Далее принимают очередной пакет сообщений и повторяют перечисленные действия до тех пор, пока не будет выполнено условие Кi=Kmax (см. блок 24) и при его выполнении сравнивают (см. блок 25) адрес инициатора i-го несанкционированного ИП с адресами инициаторов ИП, содержащимися в составе опорных и неактуальных идентификаторов.

При наличии совпадения идентифицируют процесс Mi, инициировавший несанкционированный ИП. Это связано с тем, что в случае обнаружения несанкционированного ИП требуется дополнительная проверка, т.к. при установлении активного соединения в семействе протоколов TCP/IP может быть выбран любой порт [25], следовательно, необходимо определить, является ли процесс, инициировавший ИП, санкционированным. Для этого формируют пакет с запросом абоненту с адресом указанным в идентификаторе i-гo несанкционированного ИП на предоставление наименования процесса Mi, инициировавшего несанкционированный ИП, передают (см. блок 26) пакет с запросом, принимают инициатором i-гo несанкционированного ИП пакет с запросом на предоставление наименования процесса Mi и формируют пакет с ответом, содержащим наименование процесса Мi, передают (см. блок 27) его и сравнивают (см. блок 28) наименование процесса Mi с предварительно запомненными наименованиями санкционированных процессов М. При наличии указанного наименования Mi в составе предварительно заданных санкционированных процессов М дополняют (см. блок 29) массив опорных идентификаторов, для чего дополнительно запоминают в массив опорных идентификаторов новый опорный идентификатор, а его коэффициенту актуальности присваивают первоначальное значение ZОП.

В случае отсутствия совпадения наименования процесса и при отсутствии совпадения адреса инициатора с адресами инициаторов, содержащимися в опорных и неактуальных идентификаторах, принимают решение о наличии несанкционированного воздействия, после чего блокируют (см. блок 31) источник несанкционированного ИП, для чего блокируют либо процесс Mi инициировавший несанкционированный ИП, либо абонента с адресом отправителя, указанным в идентификаторе данного несанкционированного ИП, и удаляют его идентификатор. Корректируют массивы опорных и временно заблокированных идентификаторов, для чего количество несанкционированных ИП P уменьшают на единицу, после чего при выполнении условия X>0 удаляют один заблокированный идентификатор с наибольшим коэффициентом актуальности из массива временно заблокированных идентификаторов и запоминают (см. блок 35) его в массив опорных идентификаторов. Количество временно заблокированных идентификаторов X уменьшают на единицу.

После этого принимают очередной пакет сообщений и повторяют цикл сравнений и принятия решения.

В процессе работы системы защиты все изменения связанные с коррекцией параметров системы защиты и структуры АС необходимо протоколировать в подсистеме регистрации и учета системы защиты. Помимо этого необходимо своевременно уведомлять администратора безопасности обо всех событиях ИБ зарегистрированных системой защиты.

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

При этом система защиты позволяет учитывать следующие типы информационных потоков:

1. Санкционированные ИП. Идентификаторы таких ИП содержатся в массиве опорных идентификаторов, а также могут находиться (могут быть перенесены) в массивах неактуальных и временно заблокированных идентификаторов.

2. ИП, источниками которых являются санкционированные абоненты, но идентификаторы этих ИП не совпадают с опорными и хранятся в массиве несанкционированных идентификаторов. Такие ИП могут после определения наименования процесса их инициировавшего быть блокированы, либо их идентификаторы будут дополнительно внесены в массив опорных идентификаторов;

3. ИП, источниками которых являются несанкционированные абоненты и их идентификаторы хранятся в массиве несанкционированных идентификаторов. Такие ИП являются несанкционированными и должны быть блокированы.

Дополнительными положительными свойствами заявленного подхода являются: возможность объединения абонентов в группы за счет предварительного задания опорных идентификаторов санкционированных соединений и обеспечения, таким образом, сегментации АС на зоны безопасности; возможность автоматического блокирования санкционированных абонентов и групп абонентов нарушающих политику безопасности; возможность обнаружения несанкционированных воздействий не только на этапе реализации атаки, но и, что очень важно [26], на этапе сбора информации об АС нарушителем, так как при этом возникают несанкционированные информационные потоки; увеличение быстродействия системы защиты по сравнению с другими известными системами, основанными на сигнатурном методе выявления несанкционированных воздействий, за счет контроля легитимности информационных потоков вместо сопоставления каждого пакета сообщений с базой данных сигнатур известных атак; увеличение быстродействия системы защиты за счет автоматического удаления из списка опорных идентификаторов санкционированных соединений устаревших (неактуальных) идентификаторов и, следовательно, сокращения времени анализа каждого принимаемого пакета сообщений.

3.2 Макет программного комплекса защиты автоматизированных систем от несанкционированных воздействий

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

На данный момент реализован сетевой драйвер-фильтр для операционной системы Windows, осуществляющий контроль сетевого трафика проходящего через драйвер tcpip.sys. Последний создает четыре виртуальные устройства:

· \Device\Tcp

· \Device\Udp

· \Device\RawIp

· \Device\Ip

Созданный драйвер, загружается после драйвера tcpip.sys и создает прослойку между последним, и всем что будет загружено позже в стеке сетевых драйверов, т.о. обеспечивая полный контроль TCP/IP трафика на транспортном уровне.

MS Windows 2000 создавалась с учетом необходимости работы в сети, поэтому в операционную систему включена всесторонняя поддержка сетей, интегрированная с подсистемой ввода-вывода и Win32 API. К четырем базовым типам сетевого программного обеспечения относятся сервисы, API, протоколы и драйверы устройств сетевых адаптеров. Все они располагаются один над другим, образуя сетевой стек. Для каждого уровня в Windows 2000 предусмотрены четко определенные интерфейсы, поэтому в дополнение к большому набору разнообразных API-функций, протоколов и драйверов адаптеров, поставляемых с Windows 2000, сторонние разработчики могут создавать собственные компоненты, расширяющие сетевую функциональность операционной системы. Чем обосновывается возможность реализации задуманных алгоритмов.

Эталонная модель OSI.

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

Чтобы помочь поставщикам в стандартизации и интеграции их сетевого программного обеспечения, международная организация по стандартизации (ISO) определила программную модель пересылки сообщений между компьютерами. Эта модель получила название эталонной модели OSI (Open System Interconnection). В ней определено семь уровней программного обеспечения:



Эталонная модель OSI.

Эталонная модель OSI -- идеал, точно реализованный лишь в очень немногих системах, но часто используемый при объяснении основных принципов работы сети. Каждый уровень на одной из машин считает, что он взаимодействует с тем же уровнем на другой машине. На данном уровне обе машины «разговаривают» на одном языке, или протоколе. Но в действительности сетевой запрос должен сначала пройти до самого нижнего уровня на первой машине, затем он передается по несущей среде и уже на второй машине вновь поднимается до уровня, который его поймет и обработает.

Уровни OSI

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

· Прикладной уровень (application layer). Обрабатывает передачу данных между двумя сетевыми приложениями, включая проверку прав доступа, идентификацию взаимодействующих машин и инициацию обмена данными.

· Презентационный уровень (presentation layer). Отвечает за форматирование данных, в том числе решает, должны ли строки заканчиваться парой символов «возврат каретки/перевод строки» (CR/LF) или только символом «возврат каретки» (CR), надо ли сжимать данные, кодировать и т. д.

· Сеансовый уровень (session layer). Управляет соединением взаимодействующих приложений, включая высокоуровневую синхронизацию и контроль за тем, какое из них «говорит», а какое «слушает».

· Транспортный уровень (transport layer). На передающей стороне разбивает сообщения на пакеты и присваивает им порядковые номера, гарантирующие прием пакетов в должном порядке. Кроме того, изолирует сеансовый уровень от влияния изменений в составе оборудования.

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

· Канальный уровень (data-link layer). Пересылает низкоуровневые кадры данных, ждет подтверждений об их приеме и повторяет передачу кадров, потерянных в ненадежных линиях связи.

· Физический уровень (physical layer). Передает биты по сетевому кабелю или другой физической несущей среде.

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

Сетевые компоненты Windows 2000.

На рис. представлена общая схема сетевых компонентов Windows 2000, их соответствие уровням модели OSI, а также протоколы, используемые различными уровнями. Как видите, между уровнями OSI и реальными сетевыми компонентами нет точного соответствия. Некоторые компоненты охватывают несколько уровней. Ниже приводится список сетевых компонентов с кратким описанием. В Сетевые API. Обеспечивают независимое от протоколов взаимодействие приложений через сеть.

· Сетевые API реализуются либо в режиме ядра и пользовательском режиме, либо только в пользовательском режиме. Некоторые сетевые API являются оболочками других API и реализуют специфическую модель программирования или предоставляют дополнительные сервисы. (Термином «сетевые API» обозначаются любые программные интерфейсы, предоставляемые сетевым программным обеспечением.)

· Клиенты TDI (Transport Driver Interface). Драйверы устройств режима ядра, обычно реализующие ту часть сетевого API, которая работает в режиме ядра. Клиенты TDI называются так из-за того, что пакеты запросов ввода-вывода (IRP), которые они посылают драйверам протоколов, форматируются по стандарту Transport Driver Interface (документированному в DDK). Этот стандарт определяет общий интерфейс программирования драйверов устройств режима ядра.

· Транспорты TDI. Представляют собой драйверы протоколов режима ядра и часто называются транспортами, NDlS-драйверами протоколов или драйверами протоколов. Они принимают IRP от клиентов TDI и обрабатывают запросы, представленные этими IRP. Обработка запросов может потребовать взаимодействия через сеть с другим равноправным компьютером; в таком случае транспорт TDI добавляет к данным IRP заголовки, специфичные для конкретного протокола (TCP, UDP, IPX), и взаимодействует с драйверами адаптеров через функции NDIS (также документированные в DDK). В общем, транспорты TDI связывают приложения через сеть, выполняя такие операции, как сегментация сообщений, их восстановление, упорядочение, подтверждение и повторная передача.

· Библиотека NDIS (Ndis.sys). Инкапсулирует функциональность для драйверов адаптеров, скрывая от них специфику среды Windows 2000, работающей в режиме ядра. Библиотека NDIS экспортирует функции для транспортов TDI, а также функции поддержки для драйверов адаптеров.

· Минипорт-драйверы NDIS. Драйверы режима ядра, отвечающие за организацию интерфейсов между транспортами TDI и конкретными сетевыми адаптерами. Минипорт-драйверы NDIS пишутся так, чтобы они были заключены в оболочку библиотеки NDIS. Такая инкапсуляция обеспечивает межплатформенную совместимость с потребительскими версиями Microsoft Windows. Минипорт-драйверы NDIS не обрабатывают IRP, а регистрируют интерфейс таблицы вызовов библиотеки NDIS, которая содержит указатели на функции, соответствующие функциям, экспортируемым библиотекой NDIS для транспортов TDI. Минипорт-драйверы NDIS взаимодействуют с сетевыми адаптерами, используя функции библиотеки NDIS, которые вызывают соответствующие функции HAL

Модель OSI и сетевые компоненты Windows 2000.

Фактически четыре нижних сетевых уровня часто обозначают собирательным термином «транспорт», а компоненты, расположенные на трех верхних уровнях, -- термином «пользователи транспорта».

Драйверы протоколов

Драйверы сетевых API должны принимать запросы, адресованные к API, и транслировать их в низкоуровневые запросы сетевых протоколов для передачи по сети. Драйверы API выполняют реальную трансляцию с помощью драйверов транспортных протоколов в режиме ядра. Отделение API от нижележащих протоколов придает сетевой архитектуре гибкость, позволяющую каждому API использовать множество различных протоколов. В Windows 2000 входят следующие драйверы протоколов: DLC (Data Link Control), NetBEUI, TCP/IP и NWLink. Ниже дается краткое описание каждого из этих протоколов.

· DLC является относительно примитивным протоколом, который используется некоторыми мэйнфреймами IBM и сетевыми принтерами Hewlett-Packard. Этот протокол не может быть использован сетевыми API напрямую. Приложения, которым нужен DLC, должны взаимодействовать с драйвером транспорта DLC.

· IBM и Microsoft внедрили NetBEUI в 1985 году, и Microsoft приняла NetBEUI в качестве стандартного протокола для LAN Manager и NetBIOS API. С тех пор Microsoft усовершенствовала NetBEUI, но этому протоколу все равно присущ ряд ограничений, в частности он не поддерживает маршрутизацию и показывает низкую производительность в WAN. NetBEUI (NetBIOS Extended User Interface) получил свое название из-за тесной интеграции с NetBIOS API, но драйвер протокола Microsoft NetBEUI реализует формат NetBIOS Frame (NBF). NetBEUI включен в Windows 2000 с единственной целью -- для взаимодействия с унаследованными Windows-системами (Windows NT 4 и потребительскими версиями Windows).

· Взрывное развитие Интернета и популярность TCP/IP обусловили статус этих протоколов как основных в Windows 2000. TCP/IP был разработан DARPA (Defense Advanced Research Projects Agency) в 1969 году как фундамент Интернета, поэтому характеристики TCP/IP (поддержка маршрутизации и хорошая производительность в WAN) благоприятствуют его использованию в глобальных сетях. TCP/IP -- единственный стек протоколов, устанавливаемый в Windows 2000 по умолчанию.

· NWLink состоит из протоколов Novell IPX и SPX. NWLink включен в Windows 2000 для взаимодействия с серверами Novell NetWare.

В Windows 2000 транспорты TDI в общем случае реализуют все протоколы, сопоставленные с основным стеком протоколов. Например, драйвер TCP/IP (\Winnt\System3 2\Drivers\Tcpip.sys) реализует протоколы TCP, UDP, IP, ARP, ICMP и IGMP. Для представления конкретных протоколов транспорт TDI обычно создает объекты «устройство», что позволяет клиентам получать объект «файл», представляющий нужный протокол, и выдавать ему запросы на сетевой ввод-вывод с использованием IRP. Драйвер TCP/IP создает три объекта «устройство» для представления различных протоколов, доступных клиентам TDI: \Device\Tcp, \Device\Udp и \Device\Ip.

Microsoft определила стандарт TDI (Transport Driver Interface), чтобы драйверам сетевых API не приходилось использовать отдельные интерфейсы для каждого необходимого им транспортного протокола, Как уже говорилось, интерфейс TDI по сути представляет собой правила форматирования сетевых запросов в IRP, а также выделения сетевых адресов и коммуникационных соединений. Транспортные протоколы, отвечающие стандарту TDI, экспортируют интерфейс TDI своим клиентам, в число которых входят драйверы сетевых API, например AFD и редиректор. Транспортный протокол, реализованный в виде драйвера устройства Windows 2000, называется транспортом TDI. Поскольку транспорты TDI являются драйверами устройств, они преобразуют получаемые от клиентов запросы в формат IRP.

Интерфейс TDI образуют функции поддержки из библиотеки \Winnt\Sys-tem32\Drivers\Tdi.sys вместе с определениями, включаемыми разработчиками в свои драйверы. Модель программирования TDI очень напоминает таковую в Winsock. Устанавливая соединение с удаленным сервером, клиент TDI выполняет следующие действия.

1. Чтобы выделить адрес, клиент создает и форматирует TDI IRP-пакет address open. Транспорт TDI возвращает объект «файл», который представляет адрес и называется объектом адреса (address object). Эта операция эквивалентна вызову Winsock-функции bind.

2. Далее клиент создает и форматирует TDI IRP-пакет connection open, а транспорт TDI возвращает объект «файл», который представляет соединение и называется объектом соединения (connection object). Эта операция эквивалентна вызову Winsock-функции socket.

3. Клиент сопоставляет объект соединения с объектом адреса с помощью TDI IRP-пакета associate address (для этой операции эквивалентных функций Winsock нет).

4. Клиент TDI, соглашающийся установить удаленное соединение, выдает TDI IRP-пакет listen, указывая для объекта соединения максимальное число подключений. После этого он выдает TDI IRP-пакет accept, обработка которого заканчивается либо установлением соединения с удаленной системой, либо ошибкой. Эти операции эквивалентны вызову Winsock-функций listen и accept.

5.Клиент TDI, которому нужно установить соединение с удаленным сервером, выдает TDI IRP-пакет connect, указывая объект соединения, выполняемый транспортом TDI после установления соединения или появления ошибки. Выдача TDI IRP-пакета connect эквивалентна вызову Winsock-функций connect.

TDI также поддерживает коммуникационную связь, не требующую логических соединений, для протоколов соответствующего типа, например для UDP. Кроме того, TDI предоставляет клиенту TDI средства для регистрации в транспортах TDI своих функций обратного вызова по событиям (event callbacks) (т. е. функций, вызываемых напрямую). Например, при получении данных через сеть транспорт TDI может вызвать зарегистрированную клиентом функцию обратного вызова для приема данных. Поддержка функций обратного вызова на основе событий позволяет транспорту TDI уведомлять своих клиентов о сетевых событиях, а клиенты, использующие такие функции, могут не выделять ресурсы для приема данных из сети, поскольку им доступно содержимое буферов, предоставляемых драйвером протокола TDI.

Драйверы NDIS

Когда драйверу протокола требуется получить или отправить сообщение в формате своего протокола, он должен сделать это с помощью сетевого адаптера. Поскольку ожидать от драйверов протоколов понимания нюансов работы каждого сетевого адаптера нереально (на рынке предлагается несколько тысяч моделей сетевых адаптеров с закрытой спецификацией), производители сетевых адаптеров предоставляют драйверы устройств, которые принимают сетевые сообщения и передают их через свои устройства. В 1989 году компании Microsoft и 3Com совместно разработали спецификацию Network Driver Interface Specification (NDIS), которая определяет аппаратно-независимое взаимодействие драйверов протоколов с драйверами сетевых адаптеров. Драйверы сетевых адаптеров, соответствующие NDIS, называются драйверами NDIS или мини-порт-драйверами NDIS. Windows 2000 поддерживает NDIS версии 5.

В Windows 2000 библиотека NDIS (\Winnt\System32\Drivers\Ndis.sys) реализует пограничный уровень между транспортами TDI (в типичном случае) и драйверами NDIS. Как и Tdi.sys, библиотека NDIS является вспомогательной и используется клиентами драйверов NDIS для форматирования команд, посылаемых этим драйверам. Драйверы NDIS взаимодействуют с библиотекой, чтобы получать запросы и отвечать на них. Взаимосвязи между компонентами, имеющими отношение к NDIS, показаны на рис.

Одна из целей Microsoft при разработке сетевой архитектуры состояла в том, чтобы производителям сетевых адаптеров было легче разрабатывать драйверы NDIS и переносить их код между потребительскими версиями Windows и Windows 2000. Таким образом, библиотека NDIS предоставляет драйверам не просто вспомогательные пограничные процедуры NDIS, а целую среду выполнения драйверов NDIS. Последние не являются истинными драйверами Windows 2000, поскольку не могут функционировать без инкапсулирующей их библиотеки NDIS. Этот инкапсулирующий уровень является настолько плотной оболочкой драйверов NDIS, что они не принимают и не обрабатывают IRP. Библиотека NDIS сама принимает IRP от серверов TDI и преобразует их в вызовы драйверов NDIS Драйверам NDIS также не приходится заботиться о реентерабельности, когда библиотека NDIS вызывает драйвер с новым запросом до того, как он успел обработать предыдущий запрос. Освобождение от поддержки реентерабельности кода означает, что создатели драйверов NDIS могут не думать о сложных проблемах синхронизации, которые еще больше усложняются в многопроцессорных системах.

Компоненты NDIS.

Библиотека NDIS скрывает от транспортов TDI и мини-порт-драйверов NDIS тот факт, что она использует IRP для представления сетевых запросов. С этой целью она требует от транспортов TDI создания пакета NDIS вызовом NdisAllocatePacket, после чего пакет передается ми-нипорт-драйверу NDIS вызовом одной из функций библиотеки NDIS (например, NdisSend). В Windows 2000 библиотека NDIS реализует пакеты NDIS на основе IRP, но в потребительских версиях Windows она этого не делает.

Хотя сериализация обращений к драйверам NDIS, осуществляемая библиотекой NDIS, упрощает разработку, она может помешать масштабированию многопроцессорных систем. Некоторые операции стандартных драйверов NDIS 4 версия библиотеки NDIS 4 из Windows NT 4) плохо масштабируются в многопроцессорных системах. В NDIS 5 разработчики получили возможность отказаться от такой сериализации. Драйвер NDIS 5 может сообщить библиотеке NDIS, что сериализация ему не нужна, и тогда библиотека NDIS переправляет драйверу запросы по мере получения соответствующих IRP. В этом случае ответственность за управление параллельными запросами ложится на драйвер NDIS, но отказ от сериализации окупается повышением производительности в многопроцессорных системах.

NDIS 5 также обеспечивает следующие преимущества:

· Драйверы NDIS могут сообщать, активна ли несущая сетевая среда, что позволяет Windows 2000 выводить на панель задач значок, показывающий, подключен ли компьютер к сети. Эта функция также позволяет протоколам и другим приложениям быть в курсе этого состояния и соответствующим образом реагировать. Например, транспорт TCP/IP будет использовать эту информацию, чтобы определять, когда нужно заново оценивать информацию об адресах, получаемую им от DHCP.

· Аппаратное ускорение TCP/IP-операций (TCP/IP task offload) позволяет минипорту пользоваться аппаратными функциями сетевого адаптера для выполнения таких операций, как расчет контрольных сумм пакетов и все вычисления, связанные с IP-безопасностью (IPSec). Аппаратное ускорение этих операций средствами сетевого адаптера повышает производительность системы, освобождая центральный процессор от выполнения этих задач.

· Быстрая пересылка пакетов (fast packet forwarding) позволяет сетевому адаптеру перенаправлять пакеты, не предназначенные данному компьютеру, на удаленные системы без участия центрального процессора.

· Функция Wake-On-LAN дает возможность сетевому адаптеру с соответствующей поддержкой выводить систему Windows 2000 из состояния с низким энергопотреблением при каких-либо событиях в сети. Сигнал пробуждения может быть инициирован сетевым адаптером при одном из следующих событий: подключении к несущей среде (например, подключении сетевого кабеля к адаптеру) и приеме специфичных для протокола последовательностей байтов (в случае адаптеров Ethernet -- при получении волшебного пакета, т. е. сетевого пакета с 16 копиями Ethernet-адреса адаптера подряд).

· NDIS, ориентированная на логические соединения, позволяет драйверам NDIS управлять несущей средой, требующей логических соединений, например устройствами ATM (Asynchronous Transfer Mode).

Интерфейсы, предоставляемые библиотекой NDIS драйверам NDIS для взаимодействия с сетевыми адаптерами, доступны через функции, вызовы которых транслируются непосредственно в вызовы соответствующих HAL-функций.

Выводы по разделу

1. Выполнена разработка алгоритмов функционирования программного комплекса защиты автоматизированных систем от несанкционированных воздействий.

2. Выполнена разработка макета программного комплекса защиты автоматизированных систем от несанкционированных воздействий.

3. Доказана возможность реализации системы защиты.

4. Экономическое обоснование дипломного проекта

4.1 Концепция экономического обоснования

Дипломный проект посвящен:

– анализу методов и средств защиты информации от несанкционированных воздействий;

– разработке методического обеспечения защиты автоматизированных систем от несанкционированных воздействий;

– разработка макета программного комплекса защиты автоматизированных систем от несанкционированных воздействий.

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

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

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

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

1. Программные показатели продукта (Q1);

2. Техническая поддержка продукта (Q2);

1. Маркетинговые показатели продукта (Q3);

2. Ценовые показатели (Q4);

3. Уровень стимулирования сбыта продукта (Q5).

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

где Qj - j-й показатель конкурентоспособности товара (j = 1...4);

qi0 - относительный единичный показатель качества оцениваемой продукции, определяемый по формулам:

qi0 = qi / qiБ или qi0 = qiБ/qi ,

где qi - единичный показатель оцениваемой продукции;

qiБ - единичный базовый показатель; ?i - весовой коэффициент значимости i-го показателя качества товара для потребителя; nj - количество оцениваемых единичных показателей качества.

В выражении берется первая формула, если увеличение i-го показателя благоприятно для потребителя, и вторая формула - если неблагоприятно.

Весовые коэффициенты устанавливаются такими, что выполняется условие:

Важные для потребителя показатели качества сведены в таблицу. Для каждого из них установлен весовой коэффициент ?i.

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

Если значение этого показателя больше “1”, то разрабатываемое изделие является более конкурентоспособным, чем базовое изделие.

Показатели качества изделия:

Факторы	Наименование показателя	Весовой коэффициент	Значение показателя
			Оцениваемого	Базового
Программные показатели продукта	Функциональность	0,4	10	4
	Стабильность работы	0,2	5	5
	Интерфейс пользователя	0,2	6	5
	Аппаратные требования	0,05	4	4
	Время на начальное обучение	0,05	6	5
	Совместимость с ОС	0,1	5	5
Техническая поддержка	Установка и настройка системы	0,1	6	5
	Линия поддержки	0,2	8	5
	Обучение персонала	0,1	5	4
	Совершенствование продукта и исправление ошибок	0,4	8	8
	Изменение системы с учетом требований заказчика	0,2	6	4
Маркетинговые показатели продукта	Демонстрационная версия продукта	0,2	6	4
	Имидж фирмы в данной области	0,8	4	4
Ценовые показатели	Начальная цена продукта	0,8	8	4
	Скидки крупным клиентам	0,2	6	5
Уровень стимулирования сбыта продукта	Реклама	0,5	4	4
	Сравнительные тесты	0,5	8	6

Показатели конкурентоспособности изделия:
Наименование фактора	Весовой коэффициент	Значение показателя
Программные показатели продукта	0,4	1,65
Техническая поддержка продукта	0,3	1,265
Маркетинговые показатели продукта	0,1	1,1
Ценовые показатели	0,1	1,84
Уровень стимулирования сбыта продукта	0,1	1,166666667

На основании полученных данных получаем показатель конкурентоспособности разрабатываемого изделия К = 1,45.

4.2 Краткое техническое описание разработки

Программный комплекс защиты представляет комплекса сетевой защиты с централизованным управлением.

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

– Исследование современных потребностей, технологий и тенденций развития на рынке информационной безопасности.

– Сбор информации о потребностях пользователей, классификация информации.

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

– Анализ вариантов создания системы для различных классов защищаемых объектов. Анализ имеющихся технологий для их реализации.

– Программная реализация конечного продукта (возлагается на крупного производителя ПО).

– Проведение испытаний разработанных продуктов, анализ результатов, подведение статистики.

Отличительными особенностями разрабатываемого комплекса являются:

– полный контроль трафика выбранного сегмента сети (или всей сети);

– возможность отдельного контроля сетевого трафика каждой машины в сети;

– возможность отдельного контроля сетевого трафика каждого пользователя каждой машины;

– возможность отдельного контроля сетевого трафика каждого приложения каждого пользователя каждой машины;

– возможность контроля всего трафика осуществляется путем уведомления каждой машиной сервера безопасности о всех соединениях;

– централизованное управление осуществляется сервером безопасности, контролирующего весь сетевой трафик;

– особенность: принятие решения о том разрешить-ли данный сетевой поток принимает сервер безопасности, а вот реальная обработка трафика осуществляется каждой машиной, т.о. не надо иметь супер мега гипер крутую машину которой придется обрабатывать весь трафик, да еще и каким-то магическим образом заворачивать весь трафик через эту машину и делать невозможным соединение машин на прямую, либо ставить между любыми машинами сетевой экран, он будет но виртуальным ;)

– осуществляется контроль не сетевых пакетов, а потоков, что позволяет классифицировать трафик на более высоком уровне и распределять его обработку, например, при высокой загруженности можно обрабатывать только высоко приоритетный трафик, тем самым сеть не ляжет и будет пропускать критичный трафик, тем самым сеть останется управляемой, что добавляет стабильности и вероятности гарантированного обслуживания.... Более того само деление на классы, а классы на потоки, позволяет оптимизировать саму обработку, ну зачем анализировать каждый пакет, когда достаточно идентифицировать что он относится к какому-то потоку, а дальше если поток разрешен, просто пропустить пакет, не анализируя его потроха, тем самым мы экономим процессорное время. Так же при высокой загруженности мы обрабатываем лишь высоко приоритетный трафик, на время откладывая/блокируя весь остальной. Еще особенность, если уж совсем все плохо, и машина захлебывается от обилия трафика..... можно на время блокировать все новые соединения, обрабатывая лишь уже установленные, т.о. все соединения что были установлены до подобной ситуации (например DOS атаки) будут продолжать работать.....;

– возможно реализовать настройку когда отдельно задаются правила для каждого приложения, даже более того адреса на которые каждое приложение может обращаться....;

– просто задание адреса и порта для разрешения или блокирования пакетов далеко не всегда реализует задуманное. Вот например как разрешить запросы на www.yandex.ru и запретить все остальные, ведь представляет собой не один сервер, а несколько, каждый раз когда клиент обращается на яндекс, DNS (сервер имен) дает новый ip адрес, тем самым нагрузка распределяется по разным серверам, т.е. два человека может делать запросы к физически разным машинам по одному и тому же имени.... и контроля только по ip адресам здесь явно недостаточно (микрософт имеет несколько подсетей.... насколько я смотрел больше 20 (подсетей класса С) это более 5000 ip адресов..... попробуйте задать фаерволу 5000 правил и можно идти пить чай, когда что-то будет скачиваться....;

– Все это к тому, что возможность задания гибких критериев соотнесения пакета к одному или другому потоку позволит существенно сократить объем правил, опять же экономя драгоценное процессорное время. Я полагаю Вы помните про протоколы которые осуществляют соединения 1:N (одного ко многим или многим к одному), это мультимедиа протоколы, когда один отправитель и много получателей.... т.е. одни и те же данные доставляются группе машин с пересылкой лишь одной копии данных (групповое прослушивание аудио, и просмотр видео....).;

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