В статье обсуждены вопросы разработки программного приложения по обнаружению, предотвращению и предсказанию наблюдающихся сбоев в составе локальной сети. Целью создания программного приложения является интеллектуализация его алгоритмов, где на основе статистики перехваченных сетевых пакетов принять дальнейшее решение для управления телекоммуникационным оборудованием сети. Представлены схемы обсуждаемых алгоритмов и результаты авторских исследований по выявлению уязвимостей современных сетевых протоколов передачи данных. Анализирован состав средств для обнаружения и предотвращения сетевых сбоев для самых уязвимых протоколов и самого популярного стандарта управления оборудованием.
Ключевые слова: компьютерная сеть, управление сетью, сбой сети, атаки, протоколы передачи данных, управление оборудованием, SNMP.
Сейчас цифровая ИТ-индустрия развивается гигантскими темпами по времени [1]. Почти каждый день появляются мобильные приложения новых сервисов, появляются веб-сайты и другие востребованные пользователями электронные ресурсы [2]. Для функционирования этих ресурсов необходимы телекоммуникационные сети (ТКС) вместе с Интернетом. Поддержание функции сети в рабочем состоянии все еще является актуальной задачей. Постоянное увеличение типов передаваемой информации и новых протоколов передачи даже не упрощает состав ТКС, а наоборот — усложняет задачу исключения простоя сети.
Авторами проведена исследовательская работа [1] по созданию инструментов (приложений) для накопления и анализа статистики, а также для принятия решений по интеллектуальному управлению сети для предотвращения сбоев.
Перечислим рассмотренные в исследованиях задачи [1]:
1) выявление способов нарушения работы сети;
2) разработка механизма сбора статистики сетевой активности;
3) анализ полученных данных по трафику сети;
4) анализ состава алгоритма обнаружения аномалий в сети;
5) предоставление механизма локализации последствий аномалий через интеллектуальное управление работой сети.
Дальнейшее описание начнем с работы механизма сбора статистики по трафику сети. На этот узел ложится основная нагрузка постоянно прослушиваемого трафика, поэтому важно, чтобы этот механизм был производительным [2]. Механизм сбора статистики данных сети основан на языке программирования С++ как самый производительный язык в процессе исполнения кода. Это основание объясняется тем, что все системные средства и библиотеки взаимодействия с сетью написаны на языке С++.
Отметим наличия возможности оптимизации исполняемых кодов под конкретный тип процессора, что позволяет задействовать дополнительные аппаратные средства, например, криптографический блок AES в процессорах Intel [3]. Архитектура механизма сбора статистики состоит из 3 основных компонентов (рисунок 1): Tshark (перехватчик пакетов), базы данных и ядро системы.
Рис. 1. Архитектура механизма сбора статистики
Tshark перехватывает пакеты и производит их сигнатурный разбор. Далее он для каждого обработанного пакета выводит в stdout строку содержащую следующую информацию следующего содержания: номер пакета, временной штамп, источник отправителя, источник получателя, протокол, длину пакета, пояснение содержание пакета [4].
Для интеграции Tshark с механизмом сбора нужно выбрать следующие инструменты:
1) Posix threads — в пределах одного процесса параллельно обрабатываются потоки;
2) Pipe — осуществляется передача данных между процессами.
Теперь заметно, что для внедрения Tshark требуется два дополнительных потока:
– 1 поток запускает Tshark с перенаправлением stdout в заранее подготовленный pipe;
– 2 прослушивает pipe и по приходу строки производит её разбор.
Из полученной такой строки в специальную структуру помещаются 4 параметра:
1) источник отправителя;
2) источник получателя;
3) протокол;
4) пояснение содержание пакета.
Далее со структурой каждого пакета работает система хранения данных, состоящий из внутренней и внешней БД. Внутренняя БД — это динамический массив данных в оперативной памяти. Внешняя БД — MySQL [5].
Такой подход обусловлен тем, что сетевые пакеты приходят во много раз чаще, чем внешняя БД способна обрабатывать запросов. Поэтому часть операций пришлось вынести во внутреннюю базу данных. К таким операциям относятся операции первичной обработки данных и подсчёт контрольной суммы md5 для более быстрой работы с БД.
Алгоритм обработки пакета внутренней БД представлен на рисунке 2 [6]. В итоге формируется внутренняя БД пакетов с их счётчиками. Раз в минуту происходит выгрузка данных во внешнюю БД по следующему алгоритму, представленному на рисунке 3.
Рис. 2. Алгоритм обработки пакета
Рис. 3. Алгоритм выгрузки данных во внешнюю БД
Внешняя БД имеет 2 типа таблиц: с данными и счётчиками пакетов. На рисунке 4 представлен пример этих таблиц packets и packets_cnt соответственно. Отдельные таблицы для счётчиков необходимы для ведения статистики на разных временных интервалах [6]: 1) на всём интервале, 2) последний месяц, 3) последняя неделя, 4) последний день, 5) последний час, 6) последние 15 минут, 7) последняя минута.
Для каждой таблицы счётчиков в определённый интервал запускается выгрузка значений счётчиков в таблицу с большим временным интервалом. Основой вывода статистики служат SQL запросы к нужной временной таблице. Такой способ удобен тем, что всю работу фильтрования результата можно поручить СУБД.
Например, подвести статистику по количеству пакетов всех сохранённых протоколов:
SELECT snifstat.packets.proto, sum(cnt) AS s
FROM snifstat.packets JOIN snifstat.packets_cnt
ON snifstat.packets.md5 = snifstat.packets_cnt.md5
GROUP BY proto
ORDER BY s desc;
Или посмотреть данные всех пакетов (рисунок 5):
SELECT * FROM snifstat.packets.
Рис. 4. Таблицы статистики
Рис. 5. Часть перехваченных пакетов
Рис. 6. Таблица Правил
Наиболее эффективное средство локализации аномалии в сети — это блокировка источника этой аномалии. Для нашей задачи использованы аппаратные средства телекоммуникационного оборудования в сочетании с внешним управлением по протоколу SNMP [9]. Протокол SNMP позволяет получать значения элементов MIB управляемого устройства. MIB — древовидная база параметров различных типов, среди которых присутствуют INTEGER, STRING, TIME [10].
Теперь рассмотрим алгоритм обнаружения аномалий [7]. Основой алгоритма является анализ статистических данных, а именно названия протоколов и типов сообщений. При появлении в статистике нового протокола или новых типов сообщений уже известного протокола происходит информирование системного администратора по протоколу syslog.
Такой способ информирования очень удобен, а также упрощает интеграцию с общей системой мониторинга предприятия. Администратор производит анализ данных пакетов и принимает решение о том, к какой группе опасности отнести данные тип пакетов [7]:
1) полностью безопасные пакеты — пакет не будет рассматриваться как угроза;
2) безопасные от конкретных хостов — пакет считается безопасным, если исходит от конкретного хоста или группы хостов, иначе — блокировка источника;
3) потенциально опасные — до определённого порога пакетов в единицу времени считаются безопасными, по превышению этого порога наступают блокирующие действия. Алгоритм обработки пакетов по этому Правилу представлен на рисунке 7;
4) опасные пакеты — моментальная блокировка источника пакета.
На хранение данных Правил в БД выделена отдельная таблица, формат которой представлен на рисунке 6. В этой таблице указаны следующие параметры: rule_id — уникальный идентификатор Правила, type — тип пакета, protocol — название протокола, protocol_info — дополнительная информация и пакете, src — источник пакета, limit — ограничение количества пакетов, limit_interval — интервал учёта лимита пакетов.
Рис. 7. Алгоритм обработки пакетов с временным ограничением
Рис. 8. Алгоритм обнаружения аномалий протокола ARP
Дополнительно в помощь администратору разработаны алгоритмы обнаружения аномалий в полностью автоматическом режиме (рисунки 7 и 8). Алгоритм обнаружения аномалий протокола ARP (рисунок 8) реализуется в 2 этапа [8]:
1 этап. Обучение — выучивание связок MAC — IP.
2 этап. Слежение — регистрация изменений с последующими действиями.
Алгоритм обнаружения аномалий протокола ICMP (рисунок 9) базируется на блокировке сообщений некоторых типов: 5 тип — перенаправление, 9 тип — объявление маршрутизатора, 10 тип — запрос маршрутизатора. Блокировка сообщений типа 5 и 9 будут срабатывать на злоумышленнике, в то время как 10 тип сработает на клиенте, предотвращая замену безопасного маршрутизатора, полученного по DHCP. В этом случае требуется уведомление администратора по средствам syslog.
Рис. 9. Алгоритм обнаружения аномалий протокола ICMP
Рис. 10. Алгоритм изоляции источника аномалии
При управлении оборудованием конечные клиенты подключаются к Ethernet коммутатором. Поэтому принято решение управлять только коммутаторами. В сети используются коммутаторы фирмы Cisco (модели: 2950, 2960 и 3750). Они схожи в управлении и имеют почти идентичные MIB. Для блокировки злокачественного клиента необходимо знать его MAC или IP адрес. Общий алгоритм отключения порта представлен на рисунке 10. Для его реализации требуются следующие узлы:
1 узел. База коммутаторов с их данными для подключения.
2 узел. База связок IP — MAC и IPv6 — MAC.
3 узел. SNMP Manager для взаимодействия с коммутаторами.
База с данными для подключения к коммутаторам хранится в MySQL в виде таблицы (рисунок 11). Здесь: sw_id — уникальный идентификатор коммутатора, sw_ip — IP-адрес коммутатора, snmp_community — строка авторизации протекла SNMP.
Рис. 11. Справочник коммутаторов
Рис.12. Таблица актуальных сетевых узлов
Для получения базы связок IP — MAC и IPv6 — MAC используется готовое приложение с открытыми исходными кодами addrwatch. Эта утилита прослушивает сетевой интерфейс и перехватывает arp пакеты, составляя по ним актуальную базу данных. Утилита поддерживает несколько способов вывода данных:
1 способ. Stdout — построчный вывод изменений в окно терминала.
2 способ. Syslog — протокол для службы регистрации сообщений о системных событиях. Для регистрации подобных сообщений создано большое количество программного обеспечения с различным функционалом.
3 способ. MySQL — выгрузка готовой базы в виде таблицы (рисунок 12).
На рисунке 12 приняты обозначения: hostname — имя компьютера который заносит запись в таблицу (в данном случае это имя одного сервера), interface — имя сетевого интерфейса где был обнаружен MAC адрес, vlan_tag — номер vlan а котором был обнаружен MAC адрес, mac_address — сам MAC адрес, ip_addres — IP или IPv6 адрес.
Для построения SNMP менеджера за основу выбрана библиотека с открытыми исходными кодами Net-SNMP. Данная библиотека написана на языке C++ и обеспечивает базовые рутинные действия для работы по протоколу SNMP согласно алгоритму [1, 9]:
Шаг 1. Открыть соединение.
Шаг 2. Сконфигурировать запрос.
Шаг 3. Отправить запрос.
Шаг 4. Отправить асинхронный запрос.
Шаг 5. Получить ответ.
Шаг 6. Закрыть соединение.
Работа SNMP менеджера делится на 4 этапов [4–5]:
1 этап. Получение списка с IP и SNMP Community.
2 этап. Открытие соединений со всеми коммутаторами.
3 этап. Получение базово необходимых параметров.
4 этап. Периодическое сканирование коммуникационных таблиц коммутаторов для составления копии внутри процесса, что ускоряет поиск порта MAC адреса.
Для параметров коммутаторов в MIB дереве выявлено несколько ключевых веток:
1 ветка. Управление портами и прочими интерфейсами.
2 ветка. Управление сетевым мостом, в который «подключены» интерфейсы.
3 ветка. Таблица связок MAC адрес — номер порта в мосту.
4 ветка. Таблица связок номер порта в коммутаторе — ID интерфейса из первой ветки.
Для дальнейшей разработки проекта было принято решение для каждого коммутатора использовать массивы со следующими структурами:
В первую очередь для каждого коммутатора строится массив структур snmp_switch_ port_state по ветке со всеми интерфейсами. Во время выполнения данного этапа заполняются поля: id и description.
Следующим этапом идёт сканирование таблицы соответствий id интерфейса — номер порта в мосту. Пример таблицы представлен на рисунке 13, где: SNMPv2-SMI::mib-2.17.1.4.1.2.39 = INTEGER: 10035, 39 — bridge port, 10035 — id интерфейса.
Рис. 13. SNMP таблица соответствий
id интерфейса — номер порта в мосту
Для этого сканируется соответствующая ветка, по данным которым происходит перебор всех id интерфейсов и при совпадении заполняется поле bridge_port в структуре snmp_switch_port_state.
После выполнения выше описанных подготовительных мероприятий начинается циклический опрос ветки таблицы коммутации, пример которой представлен на рисунке 14, где: SNMPv2-SMI::mib-2.17.4.3.1.2 — адрес ветки, 252.69.150.227.198.3 — MAC адрес в десятичном формате (выделенная на рисунке часть), INTEGER — тип данных в листике полученного дерева, 353 — номер порта в мосту.
Рис. 14. SNMP таблица коммутации
Таким образом, SNMP Manager получает локальную копию таблицы коммутации, что значительно ускоряет работу. Сканирование веток самого коммутатора может проходить с разной скоростью, в зависимости от производительности оборудования и его загруженности. Теперь рассмотрим структуру и функции работы алгоритма отключения порта. Как только поступает команда отключить порт по MAC адресу злоумышленника, происходит:
- поиск MAC адреса по локальным копиям таблиц коммутации всех коммутаторов;
- вычисляется номер порта в мосту;
- по номеру порта в мосту вычисляется id интерфейса, и по id интерфейса на коммутатор формируется команда для перевода физического порта в состояние disable.
Блок-схема алгоритма отключения порта представлена на рисунке 15.
Рис. 15. Алгоритм отключения порта на оборудовании
Таким образом, в статье рассмотрены вопросы разработки программных приложений по обнаружению, предотвращению и предсказанию наблюдающихся сбоев в составе локальной сети. Целью рассмотрения создания программного приложения является интеллектуализация ее алгоритмов, где на основе статистики перехваченных сетевых пакетов принять дальнейшее решение для управления телекоммуникационным оборудованием сети. Представлены результаты проведенных исследований по выявлению уязвимостей современных сетевых протоколов передачи данных в сети.
В результате исследования анализирован состав средств для обнаружения и предотвращения сетевых сбоев для самых уязвимых протоколов и самого популярного стандарта управления оборудованием. Сформулированные выводы могут быть использованы средние и крупными ИТ-организациями в составе своих локальных сетей с выбранными Интернет-провайдерами. Выгода от использования рассматриваемых приложений состоит в сокращении простоя в работе сети.
Литература:
- Кульмамиров С. А., Сансызбай А., Типовые элементы интеллектуализации управления звеньями сети. Алматы: КазНУ, 2021, 7 с.
- Удалённые сетевые атаки. https://ru.wikipedia.org/wiki/удалённые_атаки. 2018.
- Безопасность канального уровня. http://xgu.ru/wiki/безопасность_каналов. 2018.
- MAC-spoofing. http://xgu.ru/wiki/MAC-spoofing. 2018.
- Захват пакетов при помощи библиотеки libpcap. http://rus-linux.net/MyLDP/algol/ libpcap.html. 2018.
- Анализ сетевого трафика на сервере при помощи tshark. https://blog.selectel.ru/analiz-setevogo-trafika-na-servere-pri-pomoshhi-tshark. 2018.
- SNMP в CISCO. http://xgu.ru/wiki/SNMP_в_Cisco. 2018.
- SNMP. http://xgu.ru/wiki/SNMP. 2018.
- Easy Hack: Хакерские секреты простых вещей. https://xakep.ru/2013/12/11/easy-hack-173. 2018.
- Уязвимость в Multicast DNS провоцирует DDoS с плечом. https://threatpost.ru/ujazvimost_multicast_dns_provotsiruet_ddos_s_plechom/7444/. 2018.
