CC BY
32
УДК 004.771:004.056.52
DOI: 10.24412/2071-6168-2022-7-46-56
МЕТОДИКА АУДИТА ОБЪЕКТОВ ИНФОРМАЦИОННОЙ ИНФРАСТРУКТУРЫ С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИИ DNS-ТУННЕЛИРОВАНИЯ
В.А. Овчаров, О.М. Степанюк, А.С. Подшибякин
В статье проанализированы актуальные угрозы сетевым ресурсам организаций при реализации удаленного несанкционированного доступа (НСД) в обход межсетевого экрана (МЭ), используя незащищенный DNS-протокол. Исследованы особенности DNS-протокола, позволяющие нарушителю информационной безопасности (ИБ) осуществлять НСД к хостам информационно-телекоммуникационной системы (ИТКС) с помощью технологии DNS-туннелирования. Разработана оригинальная методика активного аудита ИТКС с использованием созданного программного средства DNSTT, позволяющего осуществлять DNS-туннелирование через протокол HTTPS. Приведены уникальные способы выявления и противодействия анонимных несанкционированных воздействий на ИБ ИТКС с использованием угроз данного класса.
Ключевые слова: информационная безопасность, межсетевой экран, DNS-протокол, сетевой трафик, технология DNS-туннелирования, программное средство DNSTT.
Анализ современного состояния ИБ объектов информационной инфраструктуры показал, что по мере возрастания количества все более сложных, многоэтапных кибератак со стороны нарушителей появляются новые угрозы, связанные с проблемами в существующих аппаратно-программных средствах защиты информации (ЗИ) информационно-телекоммуникационных систем. Основными причинами возникновения таких угроз, как правило, являются либо ошибки из-за некорректной настройки средств, обеспечивающих ЗИ, или дефекты, связанные с наличием уязвимых конструкций в программном коде. В большинстве случаев типовым средством защиты сети является межсетевой экран, предназначенный для фильтрации доступа вредоносного контента к хостам сети и размещенный, как правило, на границе сетевого периметра. В настоящее время наиболее эффективными по обеспечению ИБ ИТКС являются МЭ компаний Cisco и Palo Alto Networks (серий NGFW), которые осуществляют не только блокировку потенциально опасных атак и нежелательных приложений, но и производят защиту от вредоносного программного обеспечения (ВПО), фильтрацию URL-адресов и т.п. [1]. Тем не менее, несмотря на постоянное совершенствование функциональных возможностей межсетевых экранов, существуют многочисленные способы обхода их для проникновения в ИТКС, связанные с особенностями DNS-протокола. Действительно, в структуре каждой сети имеется DNS-протокол, предназначенный для получения IP-адреса по доменному имени, прохождение трафика через который не подвергается контролю и фильтрации межсетевым экраном. Это может быть использовано нарушителем ИБ для создания скрытого канала, обменивающегося данными со скомпрометированными устройствами за счет применения технологии DNS-туннелирования. Данная технология туннелирования появилась в начале XX-го века, но уже через десятилетие использовалась вредоносными программами «Morto» [2] и «Feederbot» [3] для получения команд от управляющих серверов и контроля загрузки данных в Интернет, не открывая ни одного TCP/UDP-соединения с внешним сервером, а также стала вредоносной нагрузкой для точек продаж «FrameworkPOS» [4]. Следует заметить, что по данным Cisco (Annual Security Report-2017) 91.3 % ВПО использует DNS-туннелирование для осуществления передачи управляющих действий и переводов денежных средств нарушителям [5]. Более того, нарушитель при этом действует не только анонимно и скрытно, но и использует имя домена, зарегистрированного на бесплатном хостинге. Так как в последнее время наблюдается значительный рост подобных угроз ИБ ИКТС, а большая часть информационных систем не подготовлены к их предотвращению, то постоянный контроль за DNS-трафиком вынуждены вести более 32% организаций в мире.
Тем не менее, несмотря на важность рассматриваемой проблемы, публикации авторов по данной тематике представляют собой несистематизированные отдельные примеры использования туннелирования, полученные в результате собственных исследований.
Таким образом, несомненный практический интерес представляет разработка методики аудита объектов информационной инфраструктуры в ИТКС с использованием DNS-туннелирования и способов его выявления.
Анализ угроз информационной безопасности телекоммуникационной системы вследствие использования DNS-туннелирования. В настоящее время наиболее опасные угрозы ИБ возникают из-за возможности проникновения нарушителей в ИТКС при использовании ими скрытых каналов, происходящих вследствие особенностей DNS-протокола в обход межсетевого экрана с помощью технологии DNS-туннелирования.
Изначально технология DNS-туннелирования применялась в качестве инструмента при входе в информационную систему для контроля обеспечения ее безопасности в случае подключения через точки доступа в удаленных местах расположения (аэропортах, гостиницах и т.д.), а также использовалась антивирусными программами для поиска файловых сигнатур.
Однако, существуют и активно развиваются деструктивные способы использования данной технологии, суть которых заключается в формировании канала поверх DNS-протокола (туннеля) для анонимной передачи вредоносной информации в сеть, что может привести к возникновению многочисленных угроз информационной безопасности ИТКС. При этом наиболее серьезными угрозами для корпоративных сетей при использовании нарушителями DNS-туннелирования являются: утечка критических данных пользователей, удаленный контроль функционирования ресурсов сети, передача через DNS-протокол практически любой информации, позволяющей наносить огромный ущерб организациям. DNS-протокол не использует технологии аутентификации (DNSSEC) и шифрования (DNS over TLS/HTTPS), что позволяет провайдерам легко перехватывать и перенаправлять на свои серверы DNS-запросы к публичным DNS-серверам, таким как 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), OpenDNS, DynDNS и EduDNS. В связи с этим существует большое количество вариантов обмана пользователя и подделки информации о том, где на самом деле осуществляется преобразование имен в IP-адреса [6].
Проводимая таким образом тактика нарушителей направлена на захват легитимных DNS-серверов с целью перенаправления DNS-запросов на их собственные сервера. Это означает, что организации будут получать недостоверные IP-адреса, указывающие на поддельные веб-страницы под управлением нарушителей (например, через Google или FedEx), которые смогут скомпрометировать учётные записи и пароли пользователей, введенных ими на таких поддельных сайтах.
Однако, в конце 2018 г. консорциум IETF принял и опубликовал документ RFC 8484, в котором был описан подход по защите DNS-запросов через HTTPS-протокол с помощью технологии DoH (DNS over HTTPS), позволяющей проводить шифрование данных с использованием публичного и закрытого ключей [7]. Целью такого подхода является повышение ИБ ИТКС как за счет обеспечения конфиденциальности DNS-запросов, так и предотвращения возможностей манипулирования данными DNS-сервера с помощью проведения нарушителями различного вида атак, в частности, «атаки через посредника».
Технология DoH применяется браузерами Chrome и Firefox, а также DNS-серверами от Google, Cloudflare, OpenDNS и др. Однако реализация такого шифрования от Google и Cloudflare не позволяет администратору сети выявить к какому вычислительному устройству подключался пользователь, что дает возможность последнему выйти на запрещенные для него ресурсы. Список широко используемых сервисов для реализации технологии DoH приведен в источнике GitHub [8]. Принцип функционирования технологии DoH представлен на рис. 1.
Рис. 1. Структура взаимодействия DNS-клиента и DNS-резолвера c использованием
технологии DoH
Суть работы DoH-технологии с обеспечением шифрования DNS-запросов и ответов на них при задействовании протокола безопасности TLS состоит в применении протокола HTTP на прикладном уровне для дальнейшего отправления запросов на HTTPS-порт сервера, включая обычную информацию HTTP.
Из вышеизложенного следует, что современные средства сетевой безопасности не осуществляют контроль DNS-запросов, в связи с чем они являются туннелем для вредоносных воздействий нарушителей на скомпрометированный хост. Более того, в связи с выявлением новых уязвимостей ресурсов ИТКС и обновлений тактик анонимных проникновений нарушителей в сеть путем туннелирования рассматриваемая в статье проблема требует разработки методики аудита объектов информационной инфраструктуры с использованием технологии DNS-туннелирования, что представляет практическую ценность.
Методика аудита объектов информационной инфраструктуры с использованием технологии DNS-туннелирования. Методика аудита объектов информационной инфраструктуры с применением технологии DNS-туннелирования использует как известные (для реализации DNS-туннелирования совместно с технологией DoH между сервером и клиентом задействована утилита Domain Name System Turbo Tunneling (DNSTT) [9]), так и разработанные программные средства. Схема методики приведена на рис. 2 и включает следующие этапы.
Рис. 2. Схема методики аудита объектов информационной инфраструктуры с использованием Б^-туннелирования
На первом этапе необходимо подготовить DNS-сервер нарушителя, предназначенный для взаимодействия с клиентом (жертвой). Для этого в операционной системе (ОС) Windows требуется установить компилятор языка программирования Go, который представляет собой статически типизированный язык программирования от корпорации Google. [10]. Язык Go предназначен для создания различного рода приложений, но прежде всего таких, как веб-сервисы и клиент-серверные приложения. Далее следует выполнить так называемую «сборку/build» программного средства DNSTT (процесс получения информационного продукта из исходного кода, чаще всего включает компиляцию и компоновку, выполняется инструментами автоматизации, а в данном случае с помощью языка программирования Go) по команде go build.
Следующим этапом в подготовке сервера является запуск процесса генерирования пары асимметричных ключей - открытого и закрытого, по команде, представленной на рис. 3. Открытый (публичный) ключ применяется для шифрования информации и может передаваться по незащищенным каналам. Закрытый (приватный) ключ применяется для дешифровки данных, зашифрованных открытым ключом.
□ ¡ervii.pub П server.key □ ™,„.,„ [В II stt-SPIVei
SS Адм и н и страто вИСом а иди ая строка
C:\dnstt\dnsj^-server>|.\dnstt-server.exe|-gen-key -privkey-file server.key -pubkey-file server.pub privkey written to server.key pubkey written to server.pub
Рис. 3. Команда для генерации пары ключей шифрования
Из рис. 3 следует, что после выполнения данной команды в папке программного средства получены два файла, в которых хранятся сгенерированные ключи для шифрования информации.
Заключительным этапом настройки сервера является его запуск по команде представленной на рис. 4. Кроме того, для запуска сервера необходимо указать следующие основные параметры: UDP-порт DNS-протокола (порт 53); файл, содержащий закрытый ключ шифрования; доменное имя; локальный хост (TCP-адрес, на который будут перенаправляться входящие туннелированные потоки).
servefrpub lervef.key miin.90 [И draft-urvef
38 Администратор: Командная строка - .спш '.сг.ег ne u dp -prtvkcy-fhesuver.key .tk 127.0.0.1:3000
С :\dnstt\dnstt-5erver>|.\dnstt-server, exe |-udp -privkey-file server.key .tk 127.е.е.1;seee
■МП •• pubkey 8Sc67f8cfcc4flfaiseeab323eaf4cSa424î-fd52Scf7e8dlJSa-f66ae?e7fM4S
HM • •• effective M TU 932
Рис. 4. Команда запуска сервера DNS-туннелирования
Как видно из рис. 4, одним из параметров в команде для запуска сервера является доменное имя, например, example.tk. DNS-туннелирование работает за счет того, что DNS-сервер нарушителя действует как авторитетный распознаватель для определенного доменного имени и функционирует как прокси-сервер (промежуточный сервер, посредник) для перенаправления DNS-запросов. По умолчанию программное средство DNSTT (выполняет роль сервера) установило, что рекурсивный преобразователь поддерживает DNS-ответы до определенного размера и равен 1232 байта. Если выбранный распознаватель не поддерживает ответы такого размера (в выходных данных сервера будут появляться сообщения об ошибках), то необходимо указывать меньший его предел, используя параметр -mtu в команде при запуске сервера. При этом хостинг freenom (услуга по обслуживанию доменных имён) позволяет бесплатно зарегистрировать доменное имя [11].
В таблице 1 указаны основные настройки записей о соответствии имени и служебной информации в системе зарегистрированного доменного имени.
Параметры зарегистрированного доменного имени
Наименование домена DNS-запись Параметр
(имя хоста) (Тип записи) (значение записи)
example.ga А 188.***.**.218
example.ml А 188.***.**.218
example.tk NS EXAMPLE.GA
example.tk NS EXAMPLE.ML
Тип записи А (Address record) указывает на конкретный IP-адрес. По этой записи определяется к какому серверу обращаться за получением информации, когда клиент указывает название сайта, а NS-запись (Name Server) определяет доменный адрес обслуживающего его DNS-сервера.
Для доступа извне осуществляется настройка маршрутизатора (рис.5) на входящие запросы по DNS-протоколу (порт 53) с перенаправлением их на внутренний хост, на котором выполняется серверная часть программного средства DNSTT (выполняет роль DNS-сервера).
Для настройки клиентской части программного средства DNSTT используется тот же принцип сборки исполняемого файла и запуск с определёнными параметрами, которые определяют: -doh - тип обработки DNS-запросов; открытый ключ шифрования; доменное имя DNS-сервера (рис.6).
„мс тт™ J ■ „Г.П If>: 132.16a.LieO IP: <Ece>
DNS TT UDP dynamKjnter... UDP „
1 ■ 53 Пор i: 53
_ __ , , , __ IP: 192.166.1.180 IP: <-6ce>
DNb TT TCP dynamclnter.,, TCP
~ ~ ' 1орт: 53 Пор1: 53
Рис. 5. Настройка маршрутизатора на входящие запросы и перенаправление их на внутренний хост
Имя Дата изменения Тип Размер
0 dns.до
□ dns_test,go
J m dnstt-client 1
/ □http.go
/ Q http_test,go
1 ( □ main_test,go
\ 1 □ 1-
3S Администратор; Командная строка - .Vdnstt-client.exe -doh https://dn s.google/dns-query -pubkey-file se rver.piib m ustard ba si с ,tk\27.0,0.1 ;7000 -
С :\dnstt\dnstt-client.\dnstt-client.exe 1 -doh https //dns.google/dns-query -pubkey-file jserver.pub|mustardbasic.tk 127.0 0.1:7000
uTLS fingerprint Firefox 63
effective MTU 133
begin session clccdc38
Рис. 6. Настройка и запуск клиентской части DNSTT
После этого в командной строке настроенного ^^5-сервера нарушителя появится запись о созданной сессии соединения между клиентом и этим сервером (рис.7).
| S Администратор: Командная строка - .\dnstt-server.exe -udp :53 -privkey-file server,key mustardbasictk 127.0,0.1:8000 |
С:\dnstt\dnstt-server>|.\dnstt-server.exe| udp :53 -privkey-file server.key mustardbasic.tk 127.0.0.1:8009 pubkey 85c67f8cfcc4flf0180eSb323e8f4c5a4241fd528cf708dl55af66ae7e7f0d45 effective MTU 932 begin session clccdc38
Рис. 7. Запись созданной сессии между клиентом и сервером DNS
Таким образом, созданное соединение между клиентом и DNS-сервером нарушителя с помощью программного средства DNSTT позволило установить логическое соединение между двумя конечными точками взаимообмена посредством инкапсуляции DNS-протокола. На рис.8 показана часть сетевого трафика в момент запуска клиентской части программного средства DNSTT, а именно, информация о DNS-протоколе.
30 5.677388 192.168.1.169 192.168,1,1 DUS 70 Standard query 0xb752 A dns.google
Internet Protocol Version 4, Src: 192.168.1.169Dst: 192.168.1.1 User Datagram Protocol, Src Port: 56069, Dst Port: 53 Domain Name System (query) Transaction ID: 0xb752 > Flags: 0x0100 Standard query Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0
v Queries_
v|dns.google: type A., class IN~ Name: dns.google [Name Length: 10] [Label Count: 2] Type: A (Host Address) (1) Class: IN (0x0901) [Response In: 31]
Рис. 8. DNS-запрос от клиента к серверу DNS
Из рис.8 видно, что клиент с локальным IP-адресом 192.168.1.169 отправил DNS-серверу пакет с запросом на указанное доменное имя dns.google. Далее, локальный DNS-сервер, обработав данный сетевой пакет, отправил сведения клиенту (рис.9), содержащие Л-записи публичного DNS-сервера рекурсивного типа от Google.
В связи с этим, очевидно, что программное средство DNSTT при построении туннели-рования между клиентом и удалённым сервером использует технологию DoH, которая позволяет подключиться к серверу, минуя его прямое доменное имя, через посредника.
На рис.10 представлена базовая архитектура реализации скрытого канала передачи данных на основе DNS-туннелирования.
Исходя из вышеизложенного, можно сделать вывод, что с помощью рассмотренной методики нарушитель может беспрепятственно проникать в ИТКС, несмотря на контроль и фильтрацию сетевого трафика, осуществляемых программными или программно-аппаратными средствами компьютерной сети с жёстко заданными правилами по защите информации в соответствии с принятой политикой безопасности организации.
Рис. 9. Ответ от сервера DNS-клиенту с программным средством DNSTT
Следует отметить, что при разработке представленной методики использовано доменное имя с регистрацией на бесплатном хостинге, а также, в отличие от доменной зоны Яи согласно «Правилу регистрации доменных имен в доменах RU и РФ» [12], была выбрана доменная зона ТК (государственная доменная зона страны Токелау), которая при регистрации доменного имени не требует личных данных пользователя, что может быть использовано нарушителем для сокрытия своих действий в сети Интернет.
Вместе с тем, в настоящее время существует ряд известных способов по выявлению проникновений в сеть с помощью ^МХ-туннелирования. Описание таких способов проникновения, а также разработанного инструмента, позволяющего оперативно отслеживать появляющиеся в сетевом трафике аномалии, связанных с воздействием нарушителей через туннелирова-ние, представлено в следующем разделе.
Способы выявления проникновений в ИТКС при использовании DNS-туннелирования. Известно, что большая часть информационных систем не подготовлена к предотвращению угроз, вызываемых зловредным использованием ^МХ-туннелирования. Кроме того, ^МХ-туннелирование применяет технологию скрытой передачи данных, что представляет серьезную опасность для сетевой безопасности организации. В связи с этим, возникает острая необходимость в разработке способов и инструментов выявления такого туннелирования на основе контроля аномалий трафика и реализации превентивных мер по защите сети от нежелательных воздействий нарушителей.
По причине того, что ^МХ-трафик контролируется редко, многие утилиты не имеют механизма своего сокрытия в сети, что позволяет для выявления DNS-туннеля использовать следующие способы, основанные на контроле аномалий трафика.
1.Увеличенное число ^МХ-запросов.
Число запросов по DNS-протоколу, в основном, является редко меняющейся величиной, как показано на рис. 11.
Поэтому внезапное увеличение DNS-запросов может свидетельствовать о возникшей аномалии, в частности, появления DNS туннелирования (рис.12).
2. Размер DNS-запроса или его ответа превышает среднестатистический объем, равный 4060 байт, что может означать работу скрытого канала (рис.13, п.1).
3. Присутствие в трафике DNS-запросов, применяющих редко используемые ресурсные записи, таких как TXT, NULL или KEY [13] (рис.13, п.2).
4. Наличие запросов к DNS-серверам с DGA-именами (Domain Generation Algorithm). Имена легитимных доменов обычно читаемы, а DGA-имена часто используются для незаконных действий и не несут смысловой нагрузки.
5. Обращение к DNS-серверам с длинными именами. Из результатов исследования следует, что наибольшая концентрация серверов, используемых нарушителями, имеет длину около 200 символов, а нормальными считаются имена до 30 символов (рис.13, п.3).
Кроме того, инструментом, позволяющим отслеживать рассмотренные аномалии в сетевом трафике, являются системы класса NBAD (Network-based Anomaly Detection), которые содержат как встроенные правила, так и могут быть настроены самостоятельно после проведенного режима обучения.
Protocol Lengt Into
DNS 359 Standard query response 0x30ea TXT L6hvhqnholrulyzb7lod6og4ztavcacaabuusaqaeeaaaaa6aa
DNS 277 Standard query response 0x9064 TXT L6hvhqnholrulyygnketaog4ztavcacaaan5cayaheaaaabwaa
DNS 277 Standard query response 0x2785 TXT LBhvhqnholrulyyzjlttaog4ztawcacaaad2uayag4aaaabuaa
DNS 277 Standard query response 0xae2e TXT L6hvhqnholruly4vwrwtaog4ztavcacaad6ieayagmaaaabqaa
DNS 277 Standard query response 0xdd©d TXT L6hvhqnholruly2bja3daog4ztavcacaadjq2ayafuaaaabkaa
DNS 277 Standard query response 0x3ae4 TXT i6hvhqnholruly3s4madaog4ztavcacaaddomaqafinaaaabiaa
DNS 277 Standard query response 0x409b TXT L6hvhqnholruly5xh5vtaog4ztavcacaactzqaqae4aaaabeaa
DNS 277 Standard query response 0xf5dl TXT L€hvhqnholruly5pyjpdaog4ztavcacaacdhcaqaeuaaaabcaa
DNS 277 Standard query response 0x2a5e TXT L6hvhqnholruly64inpdaog4ztavcacaabvsgaqad4aaaaa4aa
DNS 277 Standard query response 0x9371 TXT L6hvhqnholruly4eamdtaog4ztavcacaablpyaiaduaaaaa2aa
DNS 277 Standard query response 0x50e3 TXT L6hvhqnholruly6wjlttaog4ztavcacaabg5kaiadmaaaaayaa
DNS 277 Standard query response 0x4ba7 TXT L6hvhqnholruly7q7xitaog4ztavcacaaatioaiac4aaaaauaa
DNS 277 Standard query response 0x9749 TXT L6hvhqnholruly4q7iytaog4ztavcacaaanwaaiacuaaaaasaa
DNS 277 Standard query response 0xf49b TXT L6hvhqnholruly5rzirdaog4ztavcacaaaitsaiacmaaaaaqaa
1 ä 1 ä
Рис. 13. Контроль аномалий, вызванных размером БИБ-запросов, запросов с использованием БСА-имен, а также их длиной
Наряду с вышеуказанными способами выявления ОМХ-туннелирования, предлагается следующая реализация превентивных мер на стороне клиента:
1. Запрет запуска нежелательного ПО. С помощью групповых политик или средства ЛррЬоекег создаются правила, запрещающие запуск тех программ, расширение которых содержатся в списке на рис.14.
^ Политика "Локальный компьютер" v jfL- Канфигурация компьютера > Q Конфигурация программ v Конфигурация Windows
> СЗ Политика разрешения имен
Сценарии (запуск/з-авершение)
> ВДВ Развернутые принтеры
v ,fL Параметры безопасности
> Политики/четны! записей
> Локальные политики
> CD Брандмауэр Windows в режиме повышенной безопасности Q Политики диспетчера списка сетей
> | Политики открытого ключа
р Н Политики ограниченного использования программ
I I Уровни Безопасности О Дополнительные правила
> [3 Политики управления приложениями
> Политики IP-безопасности на "Локальный компьютер"
> Q Конфигурация расширенной политики аудита _ill CcS нз основе политики_
Тип объекта
ИЗ Уровни безопасности ИЗ Дополнительные правила Й Применение
I Назнач!
^Доверенные издатели
Перечисленные ниже типы Файлов определяют, ч исполняемым кодом Они являются дополнением программным типам Файлов, таким как EXE. DLL
Назначенные типы файлов: Расширение Тип Файла
C:\Users\AAMHHHcrpaTop.WIN-91 PQ4EIN1 OTK\Desktop\putty.exe
О
Эта программа заблокирована системным администратором, За дополнительными сведениями обращайтесь к системному администратору.
Рис. 14. Список запрета нежелательного программного обеспечения
2. Использование непривилегированных учетных записей. Поскольку для создания туннеля необходимы действия с правами администратора, то на уровне операционной системы следует ограничить возможности пользователя.
В данной статье, учитывая необходимость в оперативности контроля DNS-трафика в ИТКС, на языке программирования Python разработан инструмент, позволяющий проводить обработку pcap-файлов для синтаксического анализа сетевого трафика и выявления необходимых параметров DNS-протокола, которые указывают на присутствие в сети реализации технологии DNS-туннелирования. Основной задачей разработанного инструмента является обнаружение в сетевом трафике таких типов ресурсных записей DNS-протокола, как TXT, NULL и KEY. На рис. 15 представлена функция gettingDataFromDNSTraffic (часть программного кода, который несет в себе набор инструкций или команд, решающих конкретную задачу), выполненная на языке Python, которая работает по следующему алгоритму: принимает переменную pkt, в которой указан pcap-файл; проверяет наличие DNS-протокола в трафике; извлекает данные о доменном имени согласно условию, соответствующего значению 16 (код типа TXT записи DNS-протокола); извлекает IP-адрес и порт источника, а также IP--адрес назначения и его порт, согласно найденному доменному имени; формирует /son-файл (рис.16).
Заметим, что разработанный инструмент по оперативному контролю факта туннели-рования в сетевом трафике можно реализовать в виде программного средства на ИТКС, который позволит осуществлять непрерывный захват трафика из сетевых интерфейсов для анализа наличия в нем атак нарушителей.
В связи с этим, для повышения эффективности фильтрации сетевого трафика ИТКС, необходимо в системное ПО перспективных МЭ внедрить функционирование разработанного инструмента, которое способно выполнять набор необходимых задач, удовлетворяющих заданным потребностям в области выявления скрытых несанкционированных воздействий нарушителя ИБ.
def gettingDataFromDNSTraffic(pkt):
json_file = "/tmp/receivedDNSProtocolData.json" data = []
if pkt.haslayerCscapy.layers.dns.DNSQR):
q_type - pkt.getlayer(scapy.layers.dns.DNSQR).qtype if q_type == 16:
q_name - pkt.getlayeriscapy.layers.dns.DNSQR).qname
q_name - q_name.decade("utf-8")
ip_src_prt - None
ip_dst_prt - None
port_src_prt = None
for ip_src in pkt:
ip_src_prt = ip_src[scapy.layers.inet.IP].src for ip_dst In pkt:
ip_dst_prt - ip_dst[scapy.layers.inet.IP].dst for port_src in pkt:
port_src_prt - port_src[scapy.layers.inet.UDP].s| for port_dst in pkt:
port_dst_prt = port_dst[scapy.layers.inet.UDP].d|
data.append(
-['Incorrect_DNS_name': q_name[:-l], 'Source.IP': ip_src_prt, 1Source_Port1: str(port_src_prt), ■Destination_IP': ip_dst_prt, 'Destination_Port': strCport_dst_prt) }■)
with openCjson_file, "a") as file: json.dump(data, file, indent=l)
Рис. 15. Функция gettingDataFromDNSTraffic для выявления подозрительных сетевых
пакетов DNS
{
" Incorrect _DNS_naiïte" : "i6hvhqnholnjTy3w4unruog4ztavcacaaafqaaaaaaaaaaaaaaaaaaqaaaaaarra. .tk",
"Source_IP": "74. .139", "Source_Port": "44043",
"Destination_IP.........168.1.188",
"Destination_Port": "53"
> ][
{
"Incorrect DNS narre" : "i6hvhqnholruly3w4unruog4ztavcacaaafqaaaaaaaaaaaaaaaaaaqaaaaaama. .tk",
" Sou rce IP" : "192.168.1.188",
"Source_Port": "53".
"Destination IP": "74. .139",
"Destination_Port": "44043"
}
M
{
"Incorrect DNS name": "i6hvhqnholrul2brt2fx5ghtbboa. .tk",
"Source_IP": "173. .6".
"5ource Port": "56357",
"Destination IP.....192.168.1.188",
"Destination Port": "53"
>
Рис. 16. Сформированный файл JSON, содержащий необходимую информацию о пакете DNS-протокола в сетевом трафике
Заключение
Возможность проникновения различного вида атак на вычислительные ресурсы ИТКС с использованием DNS-туннелирования позволяет нарушителю ИБ наносить серьезный ущерб большому количеству организаций как коммерческого, так и государственного значения. Более того, так как такие атаки проводятся анонимно и скрытно, то любой прецедент нарушения ИБ в сети не может быть подвергнут расследованию с помощью оперативно-розыскных мероприятий (например, СОРМ-з) [14].
Представленная в статье методика аудита объектов информационной инфраструктуры с использованием DNS-туннелирования представляет собой технологию последовательности этапов использования конкретных инструментов и программных средств по реализации атак на ИТКС, изучение которой позволит специалистам в области информационной безопасности разработать эффективные методы по принятию организационных и технических мер, направленных на обеспечение защиты информации от неправомерного доступа.
Разработан инструмент на языке программирования Python, позволяющий проводить синтаксический анализ сетевого трафика для определения параметров DNS-протокола, указывающих на использование в сети технологии DNS-туннелирования. Практическое использова-
ние данного инструмента позволит осуществить не только блокировку подозрительных IP-адресов и соответствующих им доменов, но и обеспечит обнаружение и предсказание вредоносных атак в реальном масштабе времени.
Для повышения уровня ИБ корпоративной сети и защиты ее от опасных атак нарушителей, использующих технологию DNS-туннелирование, необходим комплексный подход. С этой целью необходимо тщательное конфигурирование используемых средств защиты информации и проведение превентивных мер и активных действий по анализу аномалий сетевого трафика. Кроме этого, требуется разработка новых инструментов на основе перспективных технологий по оперативному выявлению и предотвращению несанкционированного вредоносного доступа к ресурсам сети с использованием туннелирования.
Список литературы
1. Cisco: Next-Generation Firewalls. [Электронный ресурс]. URL: https://www.cisc0.c0m/c/en my/products/security/firewalls/index.html (дата обращения: 23.03.2022).
2. Broadcom. Endpoint Protection: Morto worm sets a (DNS) record. [Электронный ресурс]. URL: https://www.symantec.com/connect/blogs/morto-worm-sets-dns-record (дата обращения: 23.03.2022).
3. Prof. Dr. Christian J. Dietrich. Feederbot Botnet Using DNS as Carrier for Command and Control (C2). [Электронный ресурс]. URL: https://chrisdietri.ch/post/feederbot-botnet-using-dns-command-and-control/ (дата обращения: 23.03.2022).
4. G DATA SECURITY BLOG. New FrameworkPOS variant exfiltrates data via DNS requests. [Электронный ресурс]. URL: https://www.gdatasoftware.com/blog/2014/10/23942-new-frameworkpos-variant-exfiltrates-data-via-dns-requests (дата обращения: 23.03.2022).
5. Cisco: Cisco 2017 Annual Cybersecurity Report. [Электронный ресурс]. URL: https://www.cisco.com/c/dam/m/digital/en us/Cisco Annual Cybersecurity Report 2017.pdf (дата обращения: 23.03.2022).
6. Cisco Umbrella: DNS Tunneling. [Электронный ресурс] URL: https://learn-umbrella.cisco.com/solution-briefs/dns-tunneling (дата обращения: 23.03.2022).
7. Request for Comments (RFC): DNS Queries over HTTPS (DoH). [Электронный ресурс] URL: https://datatracker.ietf.org/doc/html/rfc8484 (дата обращения: 23.03.2022).
8. GitHub: DNS-over-HTTPS. [Электронный ресурс] URL: https://github.com/curl/curl/wiki/DNS-over-HTTPS (дата обращения: 23.03.2022).
9. Domain Name System Turbo Tunneling: DNS tunnel that can use DNS-over-HTTPS. [Электронный ресурс] URL: https://www.bamsoftware.com/software/dnstt/ (дата обращения: 23.03.2022).
10. The Go programming language. [Электронный ресурс] URL: https://go.dev (дата обращения: 23.03.2022).
11. Хостинг бесплатных доменных имён. [Электронный ресурс] URL: https://www.freenom.com/ru/index.html?lang=ru (дата обращения: 23.03.2022).
12. КонсультантПлюс: Правила регистрации доменных имен в доменах RU и РФ. [Электронный ресурс] URL: http://www.consultant.ru/document/cons doc LAW 319888 (дата обращения: 23.03.2022).
13. IANA: Domain Name System (DNS) Parameters. [Электронный ресурс] URL: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml (дата обращения: 23.03.2022).
14. Гарант: Приказ Министерства связи и массовых коммуникаций РФ от 16 апреля 2014 г. N 83. [Электронный ресурс] URL: https://base.garant.ru/70674356/ (дата обращения: 23.03.2022).
Овчаров Владимир Александрович, д-р техн. наук, начальник отдела - заместитель начальника управления военного института (научно-исследовательского), vka@mil.ru, Россия, Санкт-Петербург, Военно-космическая академия имени А. Ф. Можайского,
Степанюк Орест Михайлович, канд. техн. наук, доцент, старший научный сотрудник научно-исследовательской лаборатории, vka@mil.ru, Россия, Санкт-Петербург, Военно-космическая академия имени А. Ф. Можайского,
55
Подшибякин Александр Сергеевич, младший научный сотрудник научно-исследовательской лаборатории, vka@mil.ru, Россия, Санкт-Петербург, Военно-космическая академия имени А. Ф. Можайского
INFORMATION INFRASTRUCTURE OBJECTS AUDIT METHODOLOGY USING DNS
TUNNELING
V.A. Ovcharov, O.M. Stepanuk, A.C. Podshibyakin
Article analyzes topical organization network resources threats in case of unauthorized access using unsecure DNS-protocol and bypassing firewall. The results of DNS-protocol features are explored, including ones that allow information security violator to access to information and telecommunication systems by means of DNS tunneling. Article describes the novel active information and telecommunication systems audit method using the created software tool DNSTT, that allows DNS tunneling through HTTPS protocol. The unique ways to detect and to resist such anonymous unauthorized actions by means of threats of this type.
Key words: information security, firewall, DNS-protocol, network traffic, DNS tunneling, DNSTT software.
Ovcharov Vladimir Alexandrovich, doctor of technical sciences, chief of the department -deputy chief of the Military Research Institute, vka@mil.ru, Russia, Saint-Petersburg, Military Space Academy,
Stepanuk Orest Mihailovich, candidate of technical sciences, docent, senior researcher employee in research laboratory, vka@mil.ru, Russia, Saint-Petersburg, Military Space Academy,
Podshibyakin Alexander Sergeevich, junior researcher employee in research laboratory, vka@mil.ru, Russia, Saint-Petersburg, Military Space Academy
УДК 621.396
DOI: 10.24412/2071-6168-2022-7-56-61
МОДЕЛИРОВАНИЕ ТИПОВЫХ УЧЕБНО-БОЕВЫХ МЕРОПРИЯТИЙ НА ОСНОВЕ ВЛОЖЕННЫХ СИТУАЦИОННЫХ МОДЕЛЕЙ
Н.П. Удальцов, П.А. Агеев, А.М. Кудрявцев
В статье рассматриваются основные процедуры моделирования типовых учебно-боевых мероприятий на основе вложенных ситуационных моделей с целью совершенствования способов и методов работы и повышения качества управления.
Ключевые слова: учебно-боевое мероприятие, прогнозирование, моделирование, система, объект, мониторинг, обстановка.
Одним из условий решения проблем обеспечения военной безопасности государства является возможность осуществления объективной оценки состояния различных военных и политических угроз.
Прогнозирование учебно-боевых мероприятий (УБМ), обеспечивает основу для принятия решения [1] по проблемам военной безопасности государства. Военная безопасность достигается своевременным и адекватным противодействием военным угрозам, военным, экономическим, научно-техническим, социально-информационным и ресурсным потенциалом страны.
Методология прогнозирования учебно-боевых мероприятий должна учитывать перспективы развития способов и средств вооруженной борьбы и иных сопутствующих действий потенциального противника, динамику изменения социально-экономических, социально-политических, религиозных, национальных и других противоречий, выявленных в результате
