Программные продукты и системы

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

Для решения данного вопроса в рамках системы защиты информации ИС используются различные системы обнаружения вторжений (СОВ). При этом обнаружение сетевых вторжений может осуществляться различными способами: на основании первичных данных – путем анализа (сигнатурного, эвристического, статистического) сетевого трафика – для выявления непосредственно вторжения, и на основании вторичных данных – путем кон- троля поведения сетевых процессов на узлах ИС и анализа аудита узлов ИС – для выявления следов или последствий вторжения [1].

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

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

-      в качестве контролируемого объекта рассматриваем ЛВС, объединяющую ЭВМ, – узлы ИС;

-      к ЛВС могут быть подключены один или более внешних каналов связи;

-      в ЛВС не должны использоваться средства преобразования сетевых адресов – NAT и т.п.; должна обеспечиваться однозначная идентификация каждого узла сети с любого другого ее узла;

-      на контролируемом объекте отсутствует система обнаружения вторжений.

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

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

Эффективное обнаружение сетевых вторжений – комплексный процесс, осуществляемый на различных уровнях (контролируемый объект в целом, ЛВС, сегмент ЛВС, отдельный узел сети) и различными способами (сигнатурный, эвристический, статистический анализ). В данной статье предметом рассмотрения является статистический анализ сетевого трафика (в частности, формирование такой статистики) с целью обнаружения таких типов вторжений, как DoS/DDoS-атаки, сканирование портов и узлов сети.

Статистику сетевого трафика будем рассматривать на уровне потоков; под потоком в данном случае понимаем однонаправленную последовательность IP-пакетов, проходящих за определенный период времени в точке наблюдения и обладающих общим набором свойств (ключей потока – flow keys) [2]. Обычно в качестве ключей потока выступает следующий набор данных:

-      транспортный протокол;

-      IP-адрес и сетевой порт отправителя;

-      IP-адрес и сетевой порт получателя.

Указанный в условиях рассмотрения проблемы запрет на использование средств преобразования сетевых адресов связан как раз с тем, что при их наличии набор ключей одного и того же потока будет отличаться в различных частях сети (например, перед сервером NAT и за сервером NAT [3]).

DoS/DDoS-атаки, сканирование портов и узлов сети характеризуются тем, что атакующим за небольшой период времени выполняется множество соединений с атакуемым узлом (узлами). Таким образом, во время вторжения происходит резкое увеличение числа активных потоков [4], что позволяет выявлять указанные типы атак с помощью простейшего анализа количества активных потоков.

Существуют два подхода по сбору статистики сетевого трафика для обнаружения вторжений:

-      сбор в ключевых точках сети;

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

Сбор статистики в ключевых точках сети подразумевает использование специфичных аппаратных средств (интеллектуального коммутационного оборудования, аппаратных сенсоров сетевого трафика и т.п.) или выделенных ЭВМ (шлюзов, межсетевых экранов). В этом случае классическими средствами для учета сетевого трафика и получения статистики по нему являются протоколы NetFlow [5], IPFIX [2], sFlow [6] и тому подобные протоколы, оперирующие данными сетевого и транспортного уровней базовой эталонной моде- ли взаимодействия открытых систем (ГОСТ Р ИСО/МЭК 7498-1-99). Их использование предполагает наличие сенсоров, непосредственно собирающих статистику (обычно в этом качестве выступает L3-коммутатор или маршрутизатор, но существуют и соответствующие специализированные устройства [7, 8]); полученные сенсорами данные собираются и сохраняются коллектором и впоследствии используются анализатором для оценки и формирования отчетов. Стоит отметить, что описанное выше оборудование для сбора статистики достаточно редко изначально закладывается в ИС (по причине его дороговизны, из-за отсутствия требований по обнаружению вторжений на момент проектирования ИС и т.п.). Замена уже используемого в ИС коммутационного оборудования на интеллектуальное и добавление аппаратных сенсоров зачастую весьма проблематичны по причинам экономического, технического и организационного характера.

Помимо вышесказанного, данный подход является весьма зависимым от топологии сети. Рассмотрим простейший вариант ЛВС, в котором сеть формируется единственным сетевым коммутатором (выполняющим также роль сенсора), к которому подключены все узлы сети, а также внешний канал связи. Через этот коммутатор проходит весь трафик, как внутрисетевой, так и внешний. Очевидно, что в этом случае собираемая коммутатором статистика будет полной для данной сети. Если же рассмотреть более сложный вариант ЛВС, содержащий хотя бы два коммутатора, то легко увидеть, что в этом случае часть трафика будет проходить через один коммутатор и учитываться однократно, а другая часть – через два или более коммутаторов и учитываться несколько раз (пример потоков в такой ЛВС изображен на рисунке). Как следствие, в таких случаях для формирования полной (суммарной) статистики по сети приходится на коллекторе выполнять операцию дедупликации собираемых данных, при которой полученные из нескольких источников сведения об одном и том же трафике объединяются, исключая дублирование. Данная операция весьма ресурсоемка, что приводит к необходимости использования в качестве коллектора высокопроизводительного оборудования (на­пример, в системных требованиях к программной версии коллектора SteelCentral Flow Gateway Vir­tual Edition фирмы Riverbed рекомендуется использование 4 центральных процессоров и (в зависимости от конфигурации) от 4 до 32 Гб ОЗУ [9]). Это приводит к значительному росту стоимости внедрения системы обнаружения вторжений.

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

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

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

В качестве входных данных для анализа с целью выявления рассматриваемых типов вторжений (DoS/DDoS-атаки, сканирование портов и узлов сети) выступает количество активных потоков за единицу времени. Сбор такой статистики (заключающийся в выделении отдельных потоков и подсчете их количества) является тривиальной, требующей минимальных ресурсов задачей и, следовательно, минимально влияет на производительность контролируемых узлов сети.

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

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

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

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

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

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

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

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

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

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

Литература

1.     Шелухин О.И., Сакалема Д.Ж., Филинова А.С. Обнаружение вторжений в компьютерные сети (сетевые аномалии): учеб. пособие. М.: Горячая линия–Телеком, 2013. 221 с.

2.     IETF RFC 7011. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information, September 2013.

3.     IETF RFC 3022. Traditional IP Network Address Translator (Traditional NAT), January 2001.

4.     Münz G. Traffic Anomaly Detection and Cause Identifica­tion Using Flow-Level Measurements. PhD thesis, Technische Univ. München, 2010.

5.     IETF RFC 3954. Cisco Systems NetFlow Services Export Version 9, October 2004.

6.     IETF RFC 3176. InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks, September 2001.

7.     Cisco NetFlow Generation 3000 Series Appliances. URL: http://www.cisco.com/c/en/us/products/cloud-systems-management/netflow-generation-3000-series-appliances/index.html (дата обращения: 25.12.2015).

8.     nBox. An Embedded NetFlow v5/v9/IPFIX Probe (IPv4, IPv6, MPLS). URL: http://www.ntop.org/products/netflow/nbox (дата обращения: 25.12.2015).

9.     Riverbed SteelCentral Product Family Specifications. URL: http://media-cms.riverbed.com/documents/0476_RVBD_SteelCent ral_SS_US_070615AS.pdf (дата обращения: 25.12.2015).