CC BY
137
Подходы к представлению результатов анализа сетевого трафика*
'А. И. Гетьман <[email protected]>, 1Ю. В. Маркин <[email protected]>, 'Д. О. Обыденное, <[email protected]>, 1,2 В. А. Падарян <[email protected]>, 1 А. Ю. Тихонов <[email protected]> Институт системного программирования РАН, 109004, Россия, г. Москва, ул. А. Солженицына,д. 25 2Московский государственный университет имени М.В. Ломоносова, 119991 ГСП-1, Москва, Ленинские горы
Аннотация. В статье предложены различные способы представления результатов анализа сетевого трафика, необходимость в которых возникает прежде всего в задачах обеспечения сетевой информационной безопасности. Рассмотрена возможность построения полного графа сетевых взаимодействий, а также создания временной диаграммы передачи пакетов. Эти компоненты используются при расследовании инцидентов нарушения ИБ. Временная диаграмма также применяется при анализе туннельных протоколов, поскольку позволяет аналитику определить, какие именно заголовки протоколов необходимо визуализировать. Для задач, связанных с обратной инженерией, а также отладкой сетевых протоколов, предлагается использовать журнал, в котором фиксируются ошибки разбора заголовков протоколов. Представленные графические компоненты либо не имеют аналогов среди орешоигсе-инструментов, либо улучшают уже существующие орешоигсе-решения.
Ключевые слова: анализ сетевого трафика; отладка сетевых протоколов; граф сетевых взаимодействий; визуализация; журнал ошибок разбора.
Б01: 10.15514/18РКА8-2016-28(6)-7
Для цитирования: Гетьман А.И., Маркин Ю.В. Обыденков Д.О., Падарян В.А., Тихонов А.Ю. Подходы к представлению результатов анализа сетевого трафика. Труды ИСПРАН, том 28, вып. 6, 2016, стр. 103-110. БОТ 10.15514/18РКА8-2016-28(6)-7
* Работа поддержана грантом РФФИ 15-07-07652 А
1. Введение
Во многих задачах обеспечения сетевой информационной безопасности требуется детальный анализ сетевого трафика. Среди таких задач можно выделить:
• расследование инцидентов нарушения ИБ
• анализ сетевой обстановки
• обратная инженерия/отладка сетевых протоколов
Подобные задачи, как правило, решаются не "на потоке", а путем выделения некоторого фрагмента трафика с помощью программы-сниффера и его последующего анализа. При решении этих задач критическими факторами, влияющими на скорость и эффективность, являются наличие в среде анализа графических компонент, позволяющих визуализировать различные аспекты сетевых взаимодействий, и возможности по переключению и синхронизации между этими компонентами.
2. Обзор существующих средств анализа
Большинство популярных инструментов анализа сетевого трафика либо не имеют графического интерфейса (Snort [1], The Bro Network Security Monitor [2]), либо изначально разрабатывались для решения других задач и удовлетворяют указанным требованиям лишь частично [3]. Наиболее популярным инструментом из второй группы является инструмент Wireshark [4]. Основным средством представления сетевой трассы в нём являются разобранные пакеты в виде списка, при этом только для одного выделенного пакета отображается полный стек протоколов и значения полей в заголовках этих протоколов. Пакет, как элемент списка, представляется посредством строки, состоящей из значений фиксированного набора полей, выделенных в заголовке протокола сетевого уровня (IP-адреса), а также полей заголовка протокола самого высокого уровня, который удалось разобрать. Фиксированность представления пакетов может вызывать трудности во многих случаях. В частности, это проявляется при анализе туннельных протоколов. Так протокол GRE [5] (рис. 1) предназначен для инкапсуляции пакетов сетевого уровня модели О SI в IP-пакеты: сетевой пакет, таким образом, содержит два заголовка протокола IP. В списке пакетов инструмент Wireshark отобразит поля последнего (верхнего) IP-заголовка, который с точки зрения туннельного соединения не является репрезентативным: чтобы понять, какой хост из внутренней сети инициировал взаимодействие, аналитику придется выделять каждый пакет и проверять значение поля сетевого адреса нижележащего IP-заголовка.
Другим способом визуализации сетевых соединений в Wireshark является просмотр иерархий протоколов [6], присутствующих в трассе. Однако отображение осуществляется в виде общего дерева протоколов с указанием некоторой суммарной статистики соединений, но без возможности просмотра
и перехода к конкретным представителям соединений, соответствующих заданному типу вложенности протоколов, для просмотра параметров этих соединений и дальнейшего их анализа (рис. 2).
Internet
В
ii.ii.ii.il
192.168.2."U
»192.168.2.2
-а -а
о
Рис. 1. Пример организации GRE-туннеля Fig. 1. GRE tunneling scheme.
Protocol Percent Packets Packets Percent Bytes Bytes Bits/s End P ckets End Bytes End Bits/s
V Frame 100.0 ■ 3000 100.0 ■ 2803776 160 k 0 0 0
v Ethernet 100,0 3000 1.5 42000 2401 0 0 0
v Internet Protocol Version 4 99.9 2996 2.1 59920 3426 0 0 0
v User Datagram Protocol 34.0 1021 0.3 8163 467 0 0 0
v Remote Procedure Call 33.9 1016 iaag 1651128 94 k 0 0 0
Network File System 33.9 1016 57.1 1602320 91 k 1016 1602320 91 k
v Transmission Control Protocol 8.5 256 0.5 14244 814 103 3296 188
SSH Protocol 2.6 77 0.2 4752 271 77 4752 271
Rlogin Protocol 2.5 76 0.0 1300 74 76 1300 74
v Stream Control Transmission Protocol 1.6 47 0.1 2540 145 33 1508 86
v MTP 3 User Adaptation Layer 0.5 14 0.0 640 36 6 64 3
v Signalling Connection Control Part 0.3 3 0.0 244 13 0 0 0
Malformed Packet 0.0 1 0.0 0 0 1 0 0
Internet Control Message Protocol 0.1 3 0.0 228 13 3 228 13
Data 56.0 1681 85.8 2406409 137 k 1681 2406409 137 k
Address Resolution Protocol 0.1 4 0.0 112 6 4 112 6
Pile. 2. Пример отображения вложенности взаимодействий в Wireshark. Fig. 2. Wireshark's protocol hierarchy statistics.
3. Реализованные формы представления результатов анализа и их применение
При расследовании инцидента нарушения ИБ необходимо локализовать сетевые соединения, посредством которых этот инцидент возник и развивался во времени: аналитик должен обладать некоторым критерием (или множеством таких критериев) на содержимое сетевых пакетов. Одним из подходов к решению задачи локализации является представление сетевых взаимодействий посредством графа, в котором вершинам соответствуют стороны сетевого взаимодействия, а ребра отображают факт взаимодействия и возможно некоторые его характеристики, такие как интенсивность. При этом одна и та же сторона может участвовать сразу в нескольких взаимодействиях. Далее требуется провести детальный анализ выделенных соединений:
• проследить за порядком отправки/получения пакетов
• просмотреть значения полей интересующих протоколов
• восстановить данные протоколов прикладного уровня Рассмотренные орешоигсе-инструменты не предоставляют графических компонентов для работы с такими сценариями.
Предлагаемые компоненты представления результатов разбора опираются на модель описания данных [7], используемую ядром системы анализа, разрабатываемой в ИСП РАН. В отличие от ШтевЬагк все сетевые пакеты (а не только выбранный пользователем) отображаются посредством дерева с выделенными заголовками инкапсулируемых протоколов (рис. 3). Таким образом, не возникает трудностей при работе с туннельными протоколами.
Block tree в х Data
□ #build(Un.defined}, parse(PcapFile), [OxO:Ox5F4] Л 00000040 A7 6B OA 00 00 Ol OA 00 00 02 45 00 00 64 00 14 SU. . . E. .d. . л
E Hdr(PcapHeader) 00000050 00 00 ff Ol B5 7 t' Ol Ü1 Ol Ol 02 02 02 02 08 00
0 Body(PcapBody) 00000060 43 05 00 04 00 00 00 00 00 00 00 09 33 3S A3 CD «I
B 1, Packet(PcapPacket), [0x18:0x96] 00000070 AB CD AB CD AB CD AB CD A3 CD AB CD AB CD A3 CD «I« «I« «I
0 Data(Eth), Src; c2:00:57;75;00;00, Dst; c2;01;57:75;C i:00 ooooooso A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD «I«I« «I« «I-K «I
ffl Data(rp4), From: 10.0.0.1, To: 10.0.0.2 00000090 AB CD A3 CD AB CD AB CD A3 CD AB CD AB CD A3 CD «I«I« «I« «I« «I
0 Data(Ip4), From; 1.1.1.1, To; 2.2.2.2 oooonoao AB CD A3 CD AB CD A3 CD A3 CD AB CD AB CE1|16 FO «1*1« «I« «I« .6
B 2, Packet(PcapPacket), [OxAE:Ox96] OOOOOOBO 5C 48 76 09 Ol 00 86 00 00 00 86 00 00 00 C2 00 Hv. . A.
0 Data(Eth), Src; c2:01:57;75;00:00, Dst; c2;00:57:75;C i;00 OOOOOOCO 57 7b 00 00 C2 01 57 7b UÜ 00 08 00 4b 00 00 78 Wu. .A Hu. .X
B Data(rp4), From: 10.0.0.2, To: 10.0.0.1 OOOOOODO 00 14 00 00 FF 04 A7 63 OA 00 00 02 OA 00 00 Ol ... .y
0 Data(Ip4), From; 2.2.2.2, To: 1.1.1.1 OOOOOOEO 45 00 00 64 00 14 00 00 FF Ol B5 7F 02 02 02 02 i. .d.
B 3, Packet(PcapPacket), [0x144:0x96] OOOOOOFO Ol Ol Ol Ol 00 00 43 05 00 04 00 00 00 00 00 00 K. .
Data(Eth), Src: c2:00:57:75:00:00r Dst: c2:01:57:75:C i-flO OOOOOIOO 00 09 3B 38 AB CD AB CD AB CD AB CD AB CD AB CD . ; 8« «I« «I« «I
Data(Ip4)i From: 10.0.0.1, To: 10.0.0.2 00000110 A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD «I« «I-« «I
Data(Ip4), From: 1.1.1.1, To: 2.2.2.2 00000120 AB CD A3 CD AB CD AB CD A3 CD AB CD AB CD A3 CD «I«I« «I« «I« «I
B 4, Packet(PcapPacket), [OxlDA;Ox96] 00000130 A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD A3 CD «I«Ik «I« «I« «I
0 Data(Ip4), From; 1Q.Q.Q.2, To; 10.0.0.1 00000150 86 00 00 00 C2 Ol 57 75 00 00 C2 00 57 75 00 00 . . .A Hu. A.H
B Data(rp4), From: 2.2.2.2, To: 1.1.1.1 00000160 08 00 45 00 00 78 00 15 00 00 FF 04 A7 6A OA 00 .E..X... v.s
00000170 00 01 on 00 00 - 00 nn 00 FF Ol E..d...
B Data(Eth), Src: c2:00:57:75:00:00, Dst: c2:01:57:75:0 n-nn 00000180 35 7E Ol Ol Ol Ol 02 02 02 02 08 00 42 F4 00 04 . .B
00000190 00 01 no on 00 no on 09 3B - ; AR CD - ГТ1 AR CD «I« «I
0 Data(Ip4), From: 1.1.1.1, To: 2.2.2.2 oooooiao A3 CD A3 CD A3 CD A3 CD AB CD A3 CD AB CD A3 CD «I« «I-« «I
B 6, Packet(PcapPacket), [0x306:0x96] OOOOOIBO AB CD A3 CD AB CD AB CD A3 CD AB CD AB CD AB CD «I« «I« «I
0 Data(Eth), Src; c2:01:57;75;00;00, Dst; c2;00;57:75;C i:00 oooooico AB CD AB CD AB CD AB CD A3 CD A3 CD AB CD AB CD «I« «I
B Data(Ip4), From: 10.0.0.2, To: 10.0.0.1 OOOOOIDO AB CD AB CD AB CD AB CD AB CD) |16 FO 5C 48 DO 47 «I«I« «I« .fl\ ffiG v
0 Data(Ip4), From; 2.2.2.2, To: 1.1.1.1 V
Рис. 3. Пример отображения стека протоколов для нескольких пакетов.
Fig. 3. ProtoSphere's protocol stack visualization for several packets.
Предлагается два способа визуализации сетевых взаимодействий:
• граф оконечных узлов (.Endpoints)
• граф, детализирующий сетевые взаимодействия выбранного оконечного узла {Nodes)
Оба графа строятся по дереву сетевых узлов. Сетевой узел - это обобщение понятий отправителя и получателя для сетевых протоколов. Например, для протокола IPv4 сетевой узел описывает IP-адрес, тогда как для протокола TCP - порт. Вершина (сетевой узел) В дерева является дочерней по отношению к вершине А, если В характеризует отправителя (получателя) в заголовке некоторого протокола, вложенном (в рамках сетевого пакета) в заголовок нижележащего (согласно модели OSI) протокола, в котором выделен отправитель (получатель) А.
Граф Endpoints (рис. 4а) отображает сетевые соединения, относящиеся к протоколу самого низкого уровня в анализируемом файле. В качестве вершин здесь как правило выступают MAC- или IP-адреса. Ребра соединяют сетевые узлы, между которыми был передан хотя бы один сетевой пакет.
Граф Nodes (рис. 46) детализирует сетевые взаимодействия заданного оконечного узла. При этом для каждого взаимодействия отображается весь стек сетевых протоколов. Дополнительно осуществляется фильтрация графа Nodes по содержимому сетевых пакетов, передаваемых между узлами. Заметим, что комбинация графов Endpoints и Nodes также позволяет визуализировать результаты задачи расследования сетевой обстановки, когда по трафику требуется определить, какие сетевые службы (приложения) запущены на том или ином компьютере в сети.
Рис. 4. (а) Пример графа Endpoints (б) Пример графа Nodes.
Fig. 4. (а) Endpoints gi-aph (b) Nodes g>-aph.
Для проведения детального анализа отдельного взаимодействия предлагается временная диаграмма, где каждый пакет отображается в виде стрелки с указанием отправителя и получателя (рис. 5). При этом можно указать, какие заголовки протоколов и какие поля в них должны отображаться над стрелками. Таким образом аналитик может адаптировать графический компонент под свои нужды. Следует отметить, что в анализаторе Wireshark есть аналогичный компонент [8], однако в нём отсутствует возможность настройки полей, значения которых будут отображаться для каждого пакета, что может быть неудобно, если интересующее поле отсутствует, или приводить к перегруженности отображения, если полей слишком много. Вложенность взаимодействий с указанием параметров соединений отображается в дереве разбора (рис. 6). Именно в таком виде ядро инструмента хранит результаты анализа.
Ф [1] A: Http С fient. В: Http Server Settings
St art Line : GET /icons/debian/openlogo-25-jpg HTTP/1.l\r\n., Option: \r\n
StartLine г HTTP/1,1 404 Not FoundVrVb Option: \r\n
StartLine : GET /icons/apache_pb-png HTTP/1-l\r\nj Option: \r\n
StartLine : HTTP/1-1 209 0K\r\nj Option: \r\n
St art Line : GET /favicon.ico HTTP/1,l\r\n. Option: \r\n
StartLine : HTTP/1-1 404 Not FoundXrXn,, Option: \r\n
StartLine : GET /test/ HTTP/1-l\r\n> Option: \r\n
StartLine : HTTP/1.1 2&0 0K\r\nj Option: \r\n
StartLine : GET /icons/blank.gif HTTP/1.l\r\n. Option: \r\n —►
GET /favicon.ica A HTTP/1.1..Host: localhost..User -Agent: Mozilla/ 5.0 (Xll; D; Lin ux 1636; fr; rv: 1.3.0.2) Gecko/2 0060308 Firefox/ 1.5.0.2..Accept:
irc^ge/png, =□ . 5 . .Accept-Lan guage: fx,fr fr; q—0.S,en-ua;q—H. 5, en; q=0 . . Acce pt-Encoding: gzi prdeflate..Accep t-Charset: ISO-8 859-l,utf-8.-q=0. 1T q=Q.7..Keep- ¥
Pile. 5. Пример временной диаграммы. Fig. 5. Time-based g>-aph.
B(Zl Context (Undefined) Л
E O Instance 0
O Stream #1 (PcapFile, size: 0x43051d); Opened: 0, Closed: 0
El □ Context (PcapFile); Network: ETH
El O Instance 0
E! □ Context (Eth)
El O Instance (MAC A: fa:16:3e:3d:92:cf, MAC B: ff:ff:ff:ff:ff:ff (broadcast))
El □ Context (Ip4)
□ OInstance (A: 0.0.0.0, B: 255.255.255.255)
B □ Context fUdp)
Instance (Port A: 68, Port В: 67)
El o Instance (MAC A: 00:lc:7f:30:da:ed, MAC B: ff:ff:ff:ff:ff:ff (broadcast))
El □ Context (Ip4)
BO Instance (A: 10.10.14.254, B: 255.255.255.255)
BD Context (Udp)
O Instance (Port A: 67, Port B: 68)
..■■Instance (MAC A: 00:21:d7:d4:6f:9a, MAC B: 01:80:c2:00:00:00) V
Рис. 6. Пример дерева разбора с отображением параметров соединений.
Fig. 6. ProtoSphere's protocol hierarchy statistics with display of connection settings.
При решении задач, связанных с обратной инженерией, а также отладкой сетевых протоколов, возникает необходимость в фиксации ошибок, возникающих при разборе заголовков этих протоколов. Анализаторы сетевого трафика, как правило, имеют модульную структуру: со временем появляются новые сетевые протоколы, и их необходимо поддерживать. Поддержка заключается в создании модуля, в котором локализована функциональность по работе с новым протоколом. При эксплуатации модуля могут проявляться ошибки разбора - несоответствия между кодом разборщика и данными, разбор которых осуществляется посредством данного разборщика. Журнал 108
ошибок, реализованный в системе, позволяет быстро локализовать такого рода ошибки. Ошибка разбора описывается текстовым сообщением и ссылкой на место ей возникновения - соответствующий пакет или сетевой сеанс. При работе с журналом поддерживается возможность фильтрации ошибок по протоколам.
Описанные графические компоненты синхронизированы друг с другом и допускают быстрое переключение между различными представлениями для повышения эффективности решения прикладных задач анализа сетевого трафика.
Список литературы
[1]. Snort, https://www.snort.org/, дата обращения: 10.10.2016
[2]. The Bro Network Security Monitor, https://www.bro.org/, дата обращения: 10.10.2016
[3]. Ю. В. Маркин, А. С. Санаров. Обзор современных инструментов анализа сетевого трафика. Препринты ИСП РАН, № 27, 2014
[4]. Wireshark. https://www.wireshark.org/, дата обращения: 10.10.2016
[5]. IETF RFC 2784. D. Farinacci, Т. Li, S. Hanks, D. Meyer, P. Traina, Generic Routing Encapsulation, March 2000
[6]. The Protocol Hierarchy window. https://www.wireshark.org/docs/wsug_html_chunked/ChStatHierarchy.html, дата обращения: 10.10.2016
[7]. Гетьман А.И., Маркин Ю.В., Падарян В.А., Тихонов А.Ю.. Модель представления данных при проведении глубокого анализа сетевого трафика. Труды ИСП РАН, том 27, вып. 4, 2015 г., стр. 5-22. DOI: 10.15514/ISPRAS-2015-27(4)-l
[8]. Robert Shimonski. The Wireshark Field Guide: Analyzing and Troubleshooting Network Traffic. Elsevier Science & Technology Books, 2013, 128 p.
Methods of presenting the results of network traffic analysis*
'A. I. Get'man <[email protected]>, 1Yu. V. Markin <[email protected]>, 1D. O. Obydenkov <[email protected]>, A. Padaryan <[email protected]>, 'A. Yu. Tikhonov <[email protected]> 1 Institute for System Programming of the Russian Academy of Sciences, 25, Alexander Solzhenitsyn St., Moscow, 109004, Russia 2Lomonosov Moscow State University, GSP-1, Leninskie Gory, Moscow, 119991, Russian Federation
* This work is supported by RFBR grant 15-07-07652 A
Abstract. The article proposes different methods of presenting network traffic analysis results, the need for which arises primarily in the area of network security. One of the most important tasks is to identify malicious traffic. For this purpose both the complete graph of network interactions and time-based packet diagram are presented. These components are used during investigation of information security violation incidents. The timing diagram is also used in analysis of tunneling protocols because it allows the analyst to determine which protocol headers are necessary to visualize. For tasks associated with reverse engineering and debugging of network protocols, it is proposed to use a journal which records protocol header parsing errors. Presented graphic components either have no analogues among the opensource tools or improve on existing opensource solutions.
Keywords: network traffic analysis, network protocols debugging, graph of network interactions, visualization, error log.
DOI: 10.15514/ISPRAS-2016-28(6)-7
For citation: Get'man A. I., Markin Yu. V., Obydenkov D. O., Padaryan V. A., Tikhonov A. Yu. Methods of presenting the results of network traffic analysis. Trudy ISP RAN/Proc. ISP RAS, vol. 28, issue 6, 2016, pp. 103-110 (in Russian). DOI: 10.15514/ISPRAS-2016-28(6)-7
References
[1]. Snort, https://www.snort.org/, accessed 10.10.2016
[2]. The Bro Network Security Monitor, https://www.bro.org/, accessed 10.10.2016
[3]. Yu. V. Markin, A. S. Sanarov. The modern network traffic analyzers overview. Preprinty ISP RAN [Preprints of ISP RAS], №27,2014 (in Russian)
[4]. Wireshark. https://www.wireshark.org/, accessed 10.10.2016
[5]. IETF RFC 2784. D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, Generic Routing Encapsulation, March 2000
[6]. The Protocol Hierarchy window. https://www.wireshark.org/docs/wsug_html_chunked/ChStatHierarchy.html, accessed 10.10.2016
[7]. Get'man A. I., Markin Yu. V., Padaryan V. A., Tikhonov A. Yu. Model of data handling for in-depth analysis of network traffic. Trudy ISP RAN / Proc. ISP RAS, 2015, vol. 27, issue. 4, pp. 5-22 (in Russian). DOI: 10.15514/ISPRAS-2015-27(4)-l
[8]. Robert Shimonski. The Wireshark Field Guide: Analyzing and Troubleshooting Network Traffic. Elsevier Science & Technology Books, 2013, 128 p.
