![](https://habrastorage.org/getpro/habr/upload_files/0ec/13c/5d9/0ec13c5d92fbe3104e7f27dc0c6969bd.jpg)
Когда я прочитал новость о том, что исследователи MIT обнаружили вплоть до 10% ошибок в разметке самых популярных датасетов для обучения нейросетей, то решил, что нужно рассказать и о нашем опыте работы с публичными датасетами.
Уже более пяти лет мы занимаемся анализом сетевого трафика и машинным обучением моделей обнаружения компьютерных атак. И часто используем для этого публичные наборы обучающих данных. Расскажу, с какими сложностями мы при этом столкнулись и почему больше не верим публичным датасетам.
Предыстория
В 2019 году мы с коллегами решили разобраться, можно ли усилить сигнатурную систему обнаружения компьютерных атак с помощью машинного обучения. Причём так, чтобы обобщающая способность модели машинного обучения позволила обнаруживать новые, ранее неизвестные атаки (0-day), для которых эксперты ещё не успели выпустить сигнатуры.
Для построения прототипа использовали модель типа «случайный лес» (random forest), обученную на публичном датасете CICIDS2017. Исследование было успешно завершено в 2021 году, все подробности и результаты — в научной статье или в посте. Главный вывод: методы машинного обучения применимы на практике для обнаружения компьютерных атак.
Но сегодня предлагаем обсудить один из первых шагов проведенного исследования (да и вообще любого исследования в области машинного обучения). А точнее — поговорить про выбор набора данных для обучения.
Выбор набора данных для обучения. Почему CICIDS2017?
Вернёмся на несколько минут в 2019 год и разберёмся, почему 5 лет назад мы выбрали публичный датасет CICIDS2017.
Тогда хотелось быстро проверить гипотезу: сможет ли модель машинного обучения с хорошим качеством обнаруживать компьютерные атаки в сетевом трафике. Мы составили план исследования по шагам, и сразу же возник первый вопрос: «На каких данных обучать и тестировать модель?»
Это был выбор из двух альтернатив: на своих данных или на каком-то публичном датасете. Да, можно собрать свою виртуальную инфраструктуру с несколькими серверами и хостами, запустить генераторы атак и нормального трафика, собрать и разметить сетевой трафик, получив таким образом свой набор данных. Но тогда мы решили, что это займёт слишком много времени. И не ошиблись, двумя годами позже мы собрали собственный датасет, работа заняла почти год.
Другая альтернатива — использовать уже опубликованный сторонний набор данных. Как есть. Но какой датасет выбрать, если их много? Мы решили оценить цитируемость датасетов в академических работах, и тогда программа Publish or Perish подсказала нам лидеров (абсолютные значения цитируемости, к сожалению, не сохранились в черновиках 2019 года):
KDD Cup 1999
CICIDS 2017
NSL-KDD 2009
ISCX 2012
UNSW-NB15
Kyoto 2006
DARPA 1998
CTU-13
UGR-16
CIDDS-001
С учетом того, что KDD и его модификации уже тогда считались устаревшими, датасет CICIDS2017 выглядел наиболее оправданным выбором, он чаще других использовался (и используется до сих пор) в исследовательских работах.
Коротко про датасет CICIDS2017
Датасет «Intrusion Detection Evaluation Dataset» CICIDS2017 подготовлен по результатам анализа сетевого трафика в изолированной среде, в которой моделировались действия 25 легальных пользователей, а также вредоносные действия нарушителей. Разработчик — Canadian Institute for Cybersecurity (CIC).
Набор объединяет более 50 Гб «сырых» данных в формате pcap и включает 8 предобработанных файлов в формате CSV, содержащих размеченные сессии с выделенными признаками в разные дни наблюдения. Краткое описание файлов и количественный состав набора данных представлены в таблицах ниже.
![Описание файлов набора данных CICIDS2017 Описание файлов набора данных CICIDS2017](https://habrastorage.org/getpro/habr/upload_files/230/05a/c3c/23005ac3c603843209814c140f367dd0.png)
![Количественный состав набора данных CICIDS2017 Количественный состав набора данных CICIDS2017](https://habrastorage.org/getpro/habr/upload_files/d94/bb7/a5e/d94bb7a5e096e6a84df8092a485b99a4.png)
Пример одной записи из набора данных CICIDS2017
Каждая запись соответствует сетевой сессии и характеризуется 85 признаками.
Flow ID, Source IP, Source Port, Destination IP, Destination Port, Protocol, Timestamp, Flow Duration, Total Fwd Packets, Total Backward Packets, Total Length of Fwd Packets, Total Length of Bwd Packets, Fwd Packet Length Max, Fwd Packet Length Min, Fwd Packet Length Mean, Fwd Packet Length Std, Bwd Packet Length Max, Bwd Packet Length Min, Bwd Packet Length Mean, Bwd Packet Length Std, Flow Bytes/s, Flow Packets/s, Flow IAT Mean, Flow IAT Std, Flow IAT Max, Flow IAT Min, Fwd IAT Total, Fwd IAT Mean, Fwd IAT Std, Fwd IAT Max, Fwd IAT Min, Bwd IAT Total, Bwd IAT Mean, Bwd IAT Std, Bwd IAT Max, Bwd IAT Min, Fwd PSH Flags, Bwd PSH Flags, Fwd URG Flags, Bwd URG Flags, Fwd Header Length, Bwd Header Length, Fwd Packets/s, Bwd Packets/s, Min Packet Length, Max Packet Length, Packet Length Mean, Packet Length Std, Packet Length Variance, FIN Flag Count, SYN Flag Count, RST Flag Count, PSH Flag Count, ACK Flag Count, URG Flag Count, CWE Flag Count, ECE Flag Count, Down/Up Ratio, Average Packet Size, Avg Fwd Segment Size, Avg Bwd Segment Size, Fwd Header Length.1, Fwd Avg Bytes/Bulk, Fwd Avg Packets/Bulk, Fwd Avg Bulk Rate, Bwd Avg Bytes/Bulk, Bwd Avg Packets/Bulk, Bwd Avg Bulk Rate, Subflow Fwd Packets, Subflow Fwd Bytes, Subflow Bwd Packets, Subflow Bwd Bytes, InitWinbytesforward, InitWinbytesbackward, actdatapktfwd, minsegsizeforward, Active Mean, Active Std, Active Max, Active Min, Idle Mean, Idle Std, Idle Max, Idle Min, Label
192.168.10.14-65.55.44.109-59135-443-6, 65.55.44.109, 443, 192.168.10.14, 59135, 6, 6/7/2017 9:00, 48, 1, 1, 6, 6, 6, 6, 6, 0, 6, 6, 6, 0, 250000, 41666.66667, 48, 0, 48, 48, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 20, 20, 20833.33333, 20833.33333, 6, 6, 6, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 9, 6, 6, 20, 0, 0, 0, 0, 0, 0, 1, 6, 1, 6, 513, 253, 0, 20, 0, 0, 0, 0, 0, 0, 0, 0, BENIGN
В обзорах набора данных CICIDS2017 (Intrusion2017, Panigrahi2018, Sharafaldin2018) отмечались проблемы дисбаланса классов, сложной файловой структуры, пропуска значений. Эти замечания мы приняли как некритичные, приступив к работе.
Проблемы датасета CICIDS2017
Повторимся, мы достаточно внимательно и аккуратно подошли к вопросу выбора набора данных для обучения модели. Собрали статистику, прочитали несколько обзоров, провели первые эксперименты. Идеального датасета не существует, поэтому мы приняли известные недостатки набора CICIDS2017 и взяли его в работу.
Теперь мы понимаем, что на тот момент главная проблема состояла в том, что известными были далеко не все недостатки.
Переходим к основной части. Далее подробно описаны ошибки в датасете CICIDS2017, с которыми мы столкнулись. Нет, слово ошибка выглядит грубо, безапелляционно и неуважительно к авторам набора данных, будем использовать слово проблема.
На этапе предварительной обработки данных подозрительным показалось наличие двух разных признаков с одинаковыми значениями. Внимательно смотрим на признаки и их значения, обнаруживая первые проблемы.
Проблема 1. Некоторые признаки дублируются. Например, признак «Fwd Header Length»
(суммарная длина заголовков пакетов в прямом направлении — от клиента к серверу) и «Fwd Header Length.1»
являются идентичными. В работе «Network Intrusion Detection: A Comprehensive Analysis of CIC-IDS2017» ещё тщательнее проанализировали все дублирующиеся признаки.
Проблема 2. Идентификаторы сессий «Flow ID»
имеют null
значения (из 458968 записей после удаления осталось 170366 записей).
Проблема 3. Среди значений признаков «Flow Bytes/s»
и «Flow Packets/s»
встречаются нечисловые значения.
Чтобы разобраться с причинами первых проблем, решаем проверить оригинальное исследование: взять «сырой» трафик CICIDS2017 (напомним, датасет состоит из «сырых» данных в формате pcap и размеченных сетевых сессий в формате CSV), своим собственным инструментом, выделить в нём сетевые сессии и сформировать свой датасет. Наш датасет должен был совпасть с датасетом CICIDS2017.
Но датасеты не совпали. Дальнейшие исследования показали наличие проблем в исходном коде инструмента CICFlowMeter, который использовался при сборе и формировании набора данных CICIDS 2017.
Для поиска таких проблем мы обработали pcap файл с записанным трафиком своим собственным сниффером, выделили сетевые сессии и их признаки, сравнили с датасетом Thursday-WorkingHours-Morning-WebAttacks.pcap_ISCX.csv, пытаясь понять и исправить расхождения. Да, расхождения есть.
![Выбранная сессия для анализа Выбранная сессия для анализа](https://habrastorage.org/getpro/habr/upload_files/885/6bb/c97/8856bbc972bbeeeff2cac199c31c1b84.png)
Анализируем сессию «Flow ID» = «192.168.10.14-65.55.44.109-59135-443-6»
, «Source IP» = «65.55.44.109»
. У канадских исследователей два последних пакета выделены в отдельную сессию? Внимательно просматриваем исходники их сниффера и находим подтверждение в методе addPacket. Да, действительно, при поступлении первого пакета с флагом FIN сессия считается завершенной. А возможные последующие пакеты (FIN, FIN ACK, ACK) будут выделены в отдельную сессию.
Такое решение нарушает спецификацию протокола TCP, которая предусматривает, что флаг FIN просто указывает на то, что отправитель завершил передачу данных. Однако TCP-соединение должно прерываться только тогда, когда обе стороны отправили друг другу пакет FIN. В исследовании «Troubleshooting an Intrusion Detection Dataset: the CICIDS2017 Case Study» авторы уточняют, что эти так называемые «TCP придатки» составляют 25,9% (!) от всего набора данных. И важно отметить, что эти отдельно выделенные сессии размечены и тем самым вносят ошибки в набор данных.
Проблема 4. Сессии завершаются некорректно: при первом появлении в сессии пакета с флагом FIN. Возможные следующие пакеты с флагами FIN, FIN ACK и ACK, фактически относящиеся к первой незавершенной сессии, попадают во вторую сессию. Это приводит к появлению в наборе данных большого количества сессий, состоящих из одного-двух пакетов, с нулевой длиной полезной нагрузки.
Также узнаем из исследования коллег, что инструмент CICFlowMeter содержит ещё одну ошибку: не рассматривается случай сброса TCP-соединения при поступлении пакета с флагом RST. Да, в последней версии инструмента ошибка исправлена, но датасет не был обновлён.
Проблема 5. Сессии завершаются некорректно: не учитывается случай завершения сессии при поступлении пакета с флагом RST.
При проверке всех условий завершения сессий обнаружили ещё одну проблему.
Проблема 6. В исходном коде инструмента CICFlowMeter установлено значение таймаута для сессии «flowTimeout»
, равное 120 секундам. Однако в описании набора данных CICIDS2017 и в документации инструмента указывается другое значение таймаута — 600 секунд.
Идём дальше. Для той же сессии в прямом направлении зафиксирован один пакет («Total Fwd Packets» = 1
), при этом общая длина переданных пакетов в прямом направлении «Total Length of Fwd Packets» = 6
. По данным Wireshark, длина пакета = 0. Откуда разница в 6 байт? «Спускаемся» от TCP до Ethernet и обнаруживаем «неучтенные» 6 байт в виде дополнения (padding) фрейма Ethernet. Мы соглашаемся с Wireshark и считаем, что не нужно включать эти 6 байт в длину TCP пакета.
Проблема 7. Ошибочно рассчитывается длина TCP пакета — длина дополнения (padding) фрейма Ethernet прибавляется к длине TCP пакета.
![Проверка длины пакета в Wireshark Проверка длины пакета в Wireshark](https://habrastorage.org/getpro/habr/upload_files/05c/891/074/05c891074a335a19d976ca36aa540835.png)
Проверяем остальные признаки для этой сессии, совпадают все значения, кроме «Average Packet Size» = 9
. Как при двух пакетах по 6 байт получить значение 9, неясно. При этом «Packet Length Mean» = 6
, совпадает.
Начинаем проверять другие сессии, и оказывается, что часто встречаются небольшие расхождения в признаках: «Packet Length Mean»
, «Packet Length Std»
, «Packet Length Variance»
, «Average Packet Size»
. Вскрытие (восстановление исходных слагаемых по значениям средних) показало, что при срабатывании таймаута сессии длина отбрасываемого пакета ошибочно учитывается в статистике.
Проблема 8. Значения признаков «Packet Length Mean»
(средняя длина полезной нагрузки в пакетах всего потока), «Packet Length Std»
(среднеквадратическое отклонение значения длины пакета), «Packet Length Variance»
(дисперсия длины пакета) и «Average Packet Size»
(средний размер пакета, совпадает по определению с признаком «Packet Length Mean»
) рассчитываются ошибочно. Ошибка связана с двойным учетом первого пакета в структуре данных со статистикой длин пакетов сетевой сессии (1, 2, 3).
Проблема 9. Признаки «Packet Length Mean»
и «Average Packet Size»
должны иметь одинаковое значение, однако по причине логической ошибки имеют различные значения. Ошибка состоит в том, что при завершении сессии по таймеру граничный пакет попадает в статистику длин пакетов, а счетчик количества пакетов (знаменатель в выражении для расчета значения признаков «Packet Length Mean»
и «Average Packet Size»
) увеличивается только для одного из признаков (1, 2).
Следующая проблема связана с анализом subflows. Логика расчёта соответствующей группы признаков была неочевидной, пришлось даже открыть issue. К сожалению, авторы не ответили в issue, спустя пару месяцев исправили ошибку, но нас не уведомили. Изменения мы заметили сами через год, когда вернулись к анализу исходного кода, проблему закрыли тоже сами. Да, проблема в коде устранена, но версия датасета не была обновлена, и не появился раздел «Исправления и ошибки» на официальном сайте датасета.
Проблема 10. Признаки «Subflow Fwd Packets»
, «Subflow Fwd Bytes»
, «Subflow Bwd Packets»
, «Subflow Bwd Bytes»
рассчитаны некорректно из-за логической ошибки в коде CICFlowMeter на момент сбора датасета.
Итак, подытоживаем, какие ошибки в датасете CICIDS2017 нам известны сегодня (на август 2024 года):
Некоторые признаки дублируются. Например, признаки
«Fwd Header Length»
и«Fwd Header Length.1»
являются идентичными.Идентификаторы сессий
«Flow ID»
имеютnull
значения.Среди значений признаков
«Flow Bytes/s»
и«Flow Packets/s»
встречаются нечисловые значения.Сессии завершаются некорректно: при первом появлении в сессии пакета с флагом FIN. Возможные следующие пакеты с флагами FIN, FIN ACK и ACK, фактически относящиеся к первой незавершенной сессии, попадают во вторую сессию. Это приводит к появлению в наборе данных большого количества сессий, состоящих из одного-двух пакетов, с нулевой длиной полезной нагрузки.
Сессии завершаются некорректно: не учитывается случай завершения TCP сессии при поступлении пакета с флагом RST. В последней версии инструмента CICFlowMeter ошибка исправлена, но датасет не был обновлён.
В исходном коде инструмента CICFlowMeter установлено значение таймаута для сессии
«flowTimeout»
, равное 120 секундам. Однако в описании набора данных CICIDS 2017 и в документации инструмента указывается другое значение таймаута — 600 секунд.Ошибочно рассчитывается длина TCP пакета — длина дополнения (padding) фрейма Ethernet прибавляется к длине TCP пакета.
Значения признаков
«Packet Length Mean»
,«Packet Length Std»
,«Packet Length Variance»
и«Average Packet Size»
рассчитываются ошибочно.Признаки
«Packet Length Mean»
и«Average Packet Size»
должны иметь одинаковое значение, однако по причине логической ошибки имеют различные значения.Признаки
«Subflow Fwd Packets»
,«Subflow Fwd Bytes»
,«Subflow Bwd Packets»
,«Subflow Bwd Bytes»
рассчитаны некорректно из-за логической ошибки в коде CICFlowMeter на момент сбора датасета.
Список из 10 пунктов выглядит красиво, но, к сожалению, это ещё не всё.
Ещё проблемы
Через два года, приступив к сбору собственного датасета веб-атак, мы фактически повторили часть экспериментов разработчиков набора данных CICIDS2017. И свои результаты сопоставили с оригинальными, обнаружив новые проблемы.
Эти проблемы носят другой характер, их точно нельзя назвать ошибками. Скорее, это обнаруженные особенности сбора датасета CICIDS2017, показывающие его неполноту:
При проверке разметки сессий с конкретными веб-атаками оказалось, что эти сессии имеют в среднем схожую продолжительность. Это свидетельствует о том, что при использовании генераторов атак не изменялись параметры межпакетных задержек и количества потоков генерации. Т.е. не изменялся тип веб-атак: «быстрые» или «медленные».
Анализ сессий с XSS атаками показал, что в наборе данных отмечены адреса только двух участвующих сторон: источника атаки и атакуемого веб-приложения. Реализация отраженных XSS атак без учёта третьей стороны носит ограниченный характер.
В описании набора данных CICIDS2017 не указано, по какому протоколу осуществлялся доступ к атакуемому веб-приложению. Анализ исходных pcap файлов позволяет установить, что использовался протокол HTTP. Отсутствуют размеченные сессии для протокола HTTPS, доля трафика которого в реальных сетях существенно превышает долю трафика протокола HTTP.
На этом мы остановились, хотя в публичной критике датасета CICIDS2017 почти наверняка можно найти и другие замечания.
Какой он, идеальный датасет?
Разобрав проблемы одного из наиболее цитируемых в мире датасетов для обучения систем обнаружения атак, невольно задаёшься вопросом: «Так каким он должен быть, идеальный датасет?»
Начать поиски ответа предлагается со статьи «A Survey of Network-based Intrusion Detection Data Sets», где представлен следующий перечень требований к идеальному датасету:
Быть публично доступным.
Содержать актуальный сетевой трафик.
Сетевой трафик должен охватывать продолжительный временной интервал и содержать как все виды атак, так и нормальное пользовательское поведение, а также полезную нагрузку.
Разметка данных должна быть корректной и проверенной вручную, поскольку не существует идеальных систем обнаружения атак.
Авторы подчёркивают, что такой датасет в настоящий момент не существует. И он вряд ли когда-либо будет создан.
Мы согласны с тезисом, что невозможно создать идеальный датасет. Но считаем, что создание приближенных к идеальным, эталонных наборов данных необходимо в интересах развития предметной области. И одной из своих ближайших задач выбрали разработку таких наборов данных.
Разработчики датасета CICIDS2017 в работе «An Evaluation Framework for Intrusion Detection Dataset» представили свои требования. Главные среди них: обеспечить разнообразие сетевого оборудования, компьютеров и операционных систем в тестовой инфраструктуре, разнообразие потоков сетевого трафика по разным направлениям, разнообразие протоколов и типов атак, разметить данные атак и чистый трафик.
И ещё несколько важных для нас дополнений из статьи «Troubleshooting an Intrusion Detection Dataset: the CICIDS2017 Case Study». Набор данных должен быть воспроизводимым. А также должен быть снабжён документацией и метаданными сбора данных, включая подробную информацию о сетевой инфраструктуре и смоделированных сценариях атак.
Свой обобщённый взгляд на проблему сбора идеального датасета мы представили в статье: «Методика сбора обучающего набора данных для модели обнаружения компьютерных атак».
Выводы
Мы больше не верим публичным датасетам. Обнаруженные проблемы в отношении одного из наиболее цитируемых в мире наборов данных подтверждают необходимость обязательной верификации используемых данных.
Да, у нас есть вопросы по аккуратности разметки данных набора CICIDS2017. Да, известны десятки проблем этого датасета. Но при этом мы благодарим авторов CICIDS2017 за их труд: на этих данных обучены сотни (если не тысячи) моделей обнаружения атак во всём мире. Канадские исследователи опубликовали этот датасет и избавили всех нас от, пожалуй, самого скучного и трудоёмкого этапа машинного обучения: сбора и подготовки исходных данных.
Мы огорчены, что наши отчёты об обнаруженных проблемах, отправленные по разным каналам в CIC (на рабочую почту CIC, в личной переписке с авторами, в issues на github), остались без ответа. Уверены, публичное исправление ошибок только усилило бы датасет. Если когда-либо мы решимся опубликовать свой датасет, то будем более открытыми к критике сообщества.
Использование публичных датасетов — удел академических исследователей. Для сравнения своей модели с работами других авторов на одних и тех же данных неизвестного качества — да, подойдёт. Разработчики «боевых» систем используют свои собственные датасеты, непубличные.
Вывод, явно не следующий из материалов этого поста, но крайне важный на последующих шагах построения модели: хорошие данные — обязательное условие для построения хорошего классификатора. GIGO.
В заключение следует сказать, что история с проблемами датасета CICIDS2017 для нас завершена. В апреле 2024 года во всех открытых issues в репозитории инструмента разметки CICFlowMeter поступил одинаковый ответ от автора. Примерного содержания: «Дорогие друзья, мы рады анонсировать первую версию нового инструмента разметки NetFlowLyzer, в котором решены проблемы CICFlowMeter».
Значит, пора перевернуть страницу. И до новых встреч в новых постах, где мы проверим новый инструмент разметки и новые датасеты, собранные с его помощью!
В титульном изображении использован плакат «Нет!» Виктора Говоркова.
CrazyElf
А не было желания после этого проанализировать какой-то другой публичный датасет? Теперь это же проще должно быть, когда вы примерно знаете, какие примерно ожидать там поля, как делать анализ и какие засады вас могут поджидать. Да, это дополнительная работа, но делать выводы сразу о всех публичных датасетах на основе анализа только одного - это несколько странно. )
fisher85 Автор
Желание проанализировать другие датасеты есть, но даже с учётом полученного опыта это ресурсоёмкие операции. Найдутся ресурсы - будут новые исследования других датасетов.
Наше недоверие к публичным датасетам после десяти случаев с обнаружением ошибок (9 датасетов с ошибками в новости из подводки, десятый датасет - CICIDS2017 из нашего разбора) - естественно. Да, критическое мышление подсказывает, что не стоит делать преждевременных обобщений. Но на всякий случай останемся при своём: не будем доверять, будем проверять.
Вывод о недоверии не означает, что мы против использования публичных датасетов. Мы за, но со знанием проблем и ограничений используемых датасетов.
voldemar_d
"Я больше не верю", кмк, воспринимается как полное неприятие.
fisher85 Автор
В этом контексте неверие != неприятие.
Не верю, значит, не уверен в качестве данных и хочу проверить их перед использованием для обучения своей модели.
Неприятие датасета - это несогласие, нежелание принять, признать датасет? Мы признаём публичные датасеты. Выводы №№ 2 и 4 явно про это.
voldemar_d
Я всего лишь про заголовок. Который, кмк, слишком резкий.
fisher85 Автор
Здесь соглашаемся. Заголовок резкий. Но и огорчение большое, что столько ресурсов потрачено на поиски проблем в одном из самых цитируемых датасетов. И боль накоплена соответствующая: пост созревал долгих три года в черновиках.
Перед публикацией внимательно перечитали советы хаброавторам. И по пункту № 3 рассчитываем, что заголовок сочтут цепляющим, а не кликбейтным. И что он вызовет интерес, а не раздражение и желание поставить минус за преднамеренный обман.