Network security

Всем привет! Добро пожаловать на заключительный урок курса FortiAnalyzer Getting Started. Данный урок будет чисто теоретическим: в нем мы рассмотрим все моменты, которые связаны с сопровождением устройства и по каким-то причинам не попали в прошлые уроки. Также мы рассмотрим схему лицензирования FortiAnalyzer. Под катом представлен материал данного урока в виде статьи, а также в форме видеоурока.

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

Для увеличения уровня защищенности сети можно использовать несколько методов контроля административного доступа:

• Профили администраторов;

• Доверенные хосты;

• Административные домены.

Рассмотрим каждый из этих методов подробнее.

При создании различных учетных записей администраторов не следует давать им больше привилегий, чем необходимо для выполнения их задач. Для данной цели FortiAnalyzer использует механизм профилей администраторов. Каждый профиль содержит список привилегий, доступных администратору. В системе имеется три преднастроенных профиля администратора:

SuperUser - предоставляет доступ ко всем системным привилегиям и привилегиям на управление устройствами;

StandartUser - предоставляет доступ к привилегиям на управление устройствами, без системных привилегий;

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

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

В дополнение к профилям администраторов для контроля доступа можно настроить доверенные устройства для каждой учетной записи администратора. Они позволяют обеспечить доступ администратора только с конкретных IP-адресов - устройств или подсетей. К примеру, если настроить одно доверенное устройство с IP-адресом 192.168.232.10, то данный администратор сможет подключаться к FortiAnalyzer только с этого IP-адреса, с других доступ будет запрещен.

Причем, контроль через доверенные устройства распространяется как на Web интерфейс, так и на CLI интерфейс при доступе через SSH.

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

Администратор с профилем Super_User имеет полный доступ ко всем административным доменам. Администраторы с другими профилями имеют доступ только к тем административным доменам, к которым они привязаны - это может быть один или несколько доменов.

Вместо создания администраторов локально к FortiAnalyzer можно привязать внешние серверы аутентификации. Для верификации внешних администраторов могут использоваться LDAP, RADIUS, TACATS+, и PKI. При использовании нескольких серверов аутентификации каждый сервер необходимо привязывать отдельно.

С помощью различных механизмов мониторинга можно отслеживать поведение администраторов, а также выполнение текущих действий. В поле System Settings > Admin > Administrators можно увидеть сессии администраторов: кто сейчас активен, а также их доверенные устройства. По умолчанию только администраторы с профилем Super_User имеют доступ к данному списку.

Отследить активность администраторов можно с помощью меню System Settings > Event Log. Здесь указываются различные действия администраторов, такие как изменения конфигурации, а также удачные или неудачные попытки входа в систему.

В меню System Settings > Task Monitor можно отслеживать статус и прогресс задач, выполняемых на FortiAnalyzer.

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

Помимо создания нового административного домена для перемещения, можно отредактировать уже существующий административный домен и в процессе редактирования добавить туда устройство, которое нужно переместить.

Заметим, что при обновлении операционной системы FortiGate нет необходимости перемещать его в новый административный домен.

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

1. Необходимо проверить, достаточно ли выделенного дискового пространства для нужд перемещаемого устройства;

2. Нужны ли существующие логи для аналитики в новом административном домене? Если да, после перемещения устройства необходимо перестроить базу данных в новом административном домене.

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

Остальные моменты, связанные с сопровождением устройства, в том или ином виде обсуждались на прошлых уроках. Поэтому перейдем к лицензированию FortiAnalyzer. Для удобства элементы, составляющие годовую стоимость владения, отмечены зеленым цветом. Существует 5 вариантов покупки устройства:

Первый вариант - физическое устройство и пакет подписок, содержащий также техническую поддержку - в одном артикуле. Удобно при первоначальной покупке. Ежегодной стоимостью владения является уже отдельный пакет подписок, включающий в себя техническую поддержку. Также отдельно можно купить сервис RMA, в таком случае его цена также будет входить в стоимость ежегодного владения. Отметим, что для железного устройства FortiAnalyzer 200F сервис SOC недоступен.

Второй вариант - отдельный артикул на физическое устройство, а также отдельный артикул на пакет подписок, включающий в себя техническую поддержку. Обычно выходит дороже первого варианта. Ежегодной стоимостью владения также является пакет подписок, включающий в себя техническую поддержку. Также отдельно можно купить сервис RMA, в таком случае его цена также будет входить в стоимость ежегодного владения.

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

Четвертый вариант - отдельный артикул для базовой виртуальной машины, а также опциональный отдельный артикул на расширение памяти, он также является единоразовым, далее артикулы на техническую поддержку и сервисы IOC и RMA. Ежегодную стоимость владения в данном случае составляют сервис технической поддержки и выбранные сервисы IOC и RMA.

И последний вариант - отдельные артикулы на базовую виртуальную машину и расширение памяти, отдельный артикул с пакетом подписок, включающим в себя техническую поддержку и сервисы IOC и SOC. Также опциональный артикул - сервис RMA. Ежегодная стоимость владения в данном случае считается как цена подписки, и цена RMA, если он также выбран для покупки.

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

Ниже представлен ролик, в котором вся приведенная выше информация представлена в видеоформате:

На этом мы хотим закончить данный курс. Как и отмечалось в его начале, курс получился не слишком объемным, мы постарались вкратце описать основные принципы и возможности продукта FortiAnalyzer. Надеемся, что данный курс будет полезен тем, кто только знакомится с продукцией компании Fortinet, и с FortiAnalyzer в частности. Периодически мы выпускаем статьи, видео, и курсы по различным продуктам компании Fortinet. Чтобы их не пропустить, следите за обновлениями на наших ресурсах:

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал

Доброго дня! В наших прошлых статьях мы рассказали про концепцию Fortinet Security Fabric, а также описали продукты FortiSwitch и FortiAP. Теперь пришло время рассмотреть процесс взаимной интеграции продуктов фабрики безопасности на практике, а также познакомиться с возможностями, которые предоставляет данная интеграция. В данной статье мы рассмотрим именно процесс интеграции - постараемся построить сеть, речь о которой велась речь здесь.

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

Отталкиваться мы будем с ядра нашей фабрики безопасности - FortiGate. Выберем самую новую версию, на данный момент это 6.4.3. Теперь выберем версию операционной системы для FortiAnalyzer. Для этого воспользуемся данным документом. В левом столбце необходимо найти нужную версию ОС на FortiGate, в нашем случае это 6.4.3. Теперь ищем поля, отмеченные галочкой: это означает, что версия ОС FortiAnalyzer,указанная в данном столбце, совместима с версией 6.4.3 для FortiGate. В нашем случае совместимая версия только одна - 6.4.3. Соответственно, ее мы и выбираем.

Для выбора операционной системы FortiSwitch необходимо воспользоваться этим документом. Из него видно, что под версию 6.4.3 FortiGate подходят две ОС FortiSwitch - 6.4.3 и 6.4.4. В таких случаях вендор рекомендует выбирать последнюю версию. Так и поступим.

Теперь выберем версию операционной системы для FortiAP. В этом нам поможет следующий ресурс. У нас на тестировании находится модель FortiAP-U421EV, поэтому переходим в раздел FortiAP-U, ищем пункт FortiOS 6.4.x compatibility, и в нем ищем подходящую версию ОС FortiAP-U421EV для 6.4.3 версии FG. Это версия 6.0.4.

Остался FortiClient EMS. Рассмотрим данный документ. Из него видно, что нам необходима 6.4.x версия ОС на FortiClient EMS. По традиции возьмем самую последнюю.

Теперь, когда мы определились с версиями операционных систем, самое время перейти к интеграции. Начнем с самого простого этапа - интеграции FortiGate и FortiAnalyzer. Для этого со стороны FortiGate перейдем в меню Log Settings -> Remote Logging and Archiving. В этом разделе необходимо активировать отправку логов на FortiAnalyzer/FortiManager и использовать IP адрес FortiAnalyzer. Период отправки логов лучше установить в Real Time, чтобы на FortiAnalyzer в любой момент времени была актуальная информация. После того, как все настройки заданы, необходимо нажать на кнопку Test Connectivity. Таким образом, мы отправим запрос для авторизации нашего устройства на FortiAnalyzer:

Теперь перейдем на FortiAnalyzer в меню Device Manager. В списке у нас появилось одно неавторизованное устройство:

Нажимаем на кнопку Authorize:

На этом интеграция FortiGate и FortiAnalyzer закончена. Перейдем к интеграции FortiGate и FortiSwitch. Для данной интеграции необходимо настроить интерфейс FortiLink:

В поле Interface Member необходимо выбрать интерфейсы, которые будут служить в качестве FortiLink - это может быть один или несколько интерфейсов. В FortiGate 61F для FortiLink по умолчанию выделено 2 интерфейса. В поле Address указывается адрес интерфейса FortiLink и маска подсети - к данной подсети будут относиться все подключаемые устройства FortiSwitch. Далее идут настройки раздачи IP адресов для подключаемых устройств FortiSwitch. Этих настроек нам вполне достаточно для интеграции, теперь переходим в меню Managed FortiSwitch.

Если FortiSwitch физически подключен к интерфейсу, на котором заведен FortiLink, он должен автоматически появиться в списке устройств и иметь статус unauthorize. Мы рассмотрим способ ручного добавления FortiSwithc. Для этого нажимаем на кнопку Create New. В появившемся окне вводим серийный номер FortiSwitch, а также даем ему название:

Теперь в списке устройств появился наш FortiSwitch. Авторизовываем его с помощью кнопки Authorize. После этого необходимо немного подождать, чтобы FortiSwitch получил статус Online:

Из представленной информации мы видим, что FortiSwitch работает на версии ОС 6.2.3. Поэтому, нам нужно обновить его до версии 6.4.4. Образ данной версии необходимо взять с портала технической поддержки в разделе Download -> Firmware Images -> FortiSwitch. Здесь необходимо выбрать необходимую версию, а после образ для конкретной модели. Далее, возвращаемся на FortiGate, выделяем необходимый FortiSwitch и нажимаем на кнопку Upgrade. В меню Upload загружаем необходимый образ и нажимаем Upgrade. По истечении нескольких минут обновление будет установлено на FortiSwitch.

Теперь перейдем к FortiAP. Она подключена к FortiSwitch по 4 порту. В соответствии со схемой, которую мы разработали здесь, нам необходимо создать для нее отдельный VLAN:

Для того, чтобы FortiAP могла управляться с помощью FG, необходимо активировать опцию Security Fabric Connection в поле Administrative Access. Остальные настройки оставляем по умолчанию. Теперь переходим в поле FortiSwitch Ports и в настройках 4 порта устанавливаем Native Vlan - WLAN:

Теперь переходим в поле Managed FortiAP. В списке появилась нужная точка доступа, авторизовываем её. Переходим в настройки точки доступа и конфигурируем параметры следующим образом:

После данных настроек статус точки доступа меняется на Online. Теперь необходимо обновить точку доступа до версии 6.0.4. Для этого в списке доступных точек доступа кликаем правой кнопкой мыши по необходимой и выбираем функцию Upgrade. В этот раз воспользуемся другим вариантом обновления - через FortiGuard. В таком случае нет необходимости скачивать образ с сайта поддержки, а потом загружать его на устройство - необходимый образ скачается автоматически при запуске обновления.

После обновления интеграцию точки доступа в нашу фабрику безопасности можно считать завершенной. Остался последний этап - интеграция FortiClient EMS.

Для этого на FortiGate переходим в меню Security Fabric -> Fabric Connector -> Create New -> FortiClient EMS. Здесь указываем название коннектора, а также IP адрес сервера, на котором установлен FortiClient EMS.

Также со стороны FortiGate необходимо авторизовать сертификат FortiClient EMS. Для этого в правой части окна напротив надписи Certificate - Not Authorized нужно нажать на кнопку Authorize и дальше нажать Accept.

Теперь необходимо авторизовать FortiGate со стороны FortiClient EMS. Перейдя на FortiClient EMS мы увидим запрос с информацией о FortiGate, который пытается подключиться. Авторизуем его:

Мы установили FortiClient EMS самой последней версии - 6.4.1. Поэтому, на этом интеграцию FortiClient EMS в фабрику безопасности также можно считать завершенной.

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

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал

На фото Arthur Lee Samuel, пионер машинного обучения, демонстрирует возможности искусственного интеллекта и играет в шашки с собственной программой Checkers-Playing, одной из первых самообучающихся программ в мире. 1962 год.

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

Как разработчик средств защиты информации я в общих чертах представлял архитектуру такой системы. Но как ML инженер, который должен был научить ее, я мало что знал.

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

Вступление. Машинное обучение и информационная безопасность

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

Но как связаны машинное обучение и информационная безопасность?

Признаться, тяжело представить себе распространение технологий AI/ML в проекты и приложения информационной безопасности. Пока не пролистаешь отчет из Стэнфорда AI Index 2019 Report, 220 страниц о современном состоянии дел в области искусственного интеллекта.

Привлечение инвестиций ведущими мировыми разработчиками средств защиты информации с применением технологий искусственного интеллекта

Выводы после прочтения отчета:

1. Направление Сybersecurity (Network Security) это около 3% мировых частных инвестиций в стартапы, использующие технологии искусственного интеллекта. Впечатляюще.

2. В блокноте я подсчитал объемы привлеченных инвестиций ведущими мировыми разработчиками средств защиты информации с использованием AI (таблица на рисунке выше). В топ-10 из знакомых имён только Splunk. А кто такие Sophos, Cylance, CrowdStrike, Wangsu, Opzoon? И с какими питчами они привлекают миллиарды долларов?

3. Среди продуктов лидеров построенного рейтинга антивирусы, средства обнаружения атак, управления инцидентами, анализа защищенности, защиты от утечек, спам-фильтры, threat intelligence, почти вся номенклатура СЗИ. ML, как минимум, делает вид, что работает везде.

Итак, у меня есть желание разобраться в машинном обучении. Есть опыт в разработке средств защиты. Известны примеры успешных реализаций СЗИ c ML. Что мешает попробовать самому, с нуля разработать систему обнаружения компьютерных атак на основе машинного обучения? Вперед!

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

Последовательность шагов

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

1. Выбор набора данных для обучения системы обнаружения компьютерных атак.

2. Предварительная обработка данных.

3. Сэмплирование против дисбаланса классов.

4. Оценка значимости и отбор признаков.

5. Сокращение признакового пространства.

6. Выбор модели.

7. Настройка и обучение модели.

8. Тестирование и апробация.

Далее по шагам.

Оригинальная схема обучения с учителем от Sebastian Raschka

Шаг 1. Выбор набора данных для обучения

Для обучения системы обнаружения атак среди доступных публичных наборов данных (DARPA1998, KDD1999, ISCX2012, ADFA2013 и других) я выбрал один из наиболее актуальных (на момент начала исследования) Intrusion Detection Evaluation Dataset CICIDS2017. Разработчик Canadian Institute for Cybersecurity. Набор данных CICIDS2017 подготовлен по результатам анализа сетевого трафика в изолированной среде, в которой моделировались действия 25 легальных пользователей, а также вредоносные действия нарушителей.

Набор объединяет более 50 Гб сырых данных в формате PCAP и включает 8 предобработанных файлов в формате CSV, содержащих размеченные сессии с выделенными признаками в разные дни наблюдения. Краткое описание файлов и количественный состав набора данных представлены в таблицах ниже.

Описание файлов набора данных CICIDS2017Количественный состав набора данных CICIDS2017Пример одной записи из набора данных CICIDS2017

Хорошие данные обязательное условие для построения хорошего классификатора.

В обзорах набора данных CICIDS2017 (Intrusion2017, Panigrahi2018, Sharafaldin2018) отмечались проблемы дисбаланса классов, сложной файловой структуры, пропуска значений. Эти замечания я принял как некритичные.

Сегодня у меня есть вопросы по аккуратности разметки набора данных CICIDS2017 (связаться с авторами набора данных и задать вопросы не удалось ни по личным адресам электронной почты, ни через Canadian Institute for Cybersecurity), но именно по этой причине мне пришлось самому разработать весь pipeline начиная от сниффера и предобработки сетевых сессий, заканчивая моделью машинного обучения и тестированием в реальной сети.

Получается, больше приобрел, чем потерял.

Шаг 2. Предварительная обработка данных

Отправной точкой для проведения собственных экспериментов с датасетом CICIDS2017 послужило исследование Kahraman Kostas Anomaly Detection in Networks Using Machine Learning. При попытке воспроизведения этого исследования были обнаружены расхождения в результатах, а потом и ошибки в коде автора. Я связался в апреле 2020 года с Kahraman Kostas, мы обсудили варианты исправления ошибки, однако по состоянию на январь 2021 года код в репозитории по-прежнему некорректно оценивает значимость признаков.

Для сокращения времени вычислений в обучающей выборке был оставлен единственный класс атак веб-атаки (Brute Force, XSS, SQL Injection). Для этого я подготовил подвыборку WebAttacks на основе обработки файла Thursday-WorkingHours-Morning-WebAttacks.pcap_ISCX.csv из набора данных CICIDS2017. Набор WebAttacks включает 458968 записей, из которых 2180 относятся к веб-атакам, остальные к нормальному трафику.

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

Этапы предварительной обработки набора данных CICIDS2017 и подготовки подвыборки WebAttacks

Я храню Jupyter блокноты на Github в репозитории ml-cybersecurity, а ссылки даю на Google Colabоratory тогда код готов к запуску прямо в браузере.

Исходный код в Google Colabоratory

Матч с канадцами. Поиск и исправление ошибок в датасете

На этапе предварительной обработки данных я обнаружил погрешности в признаковом пространстве (как минимум, подозрительным показалось наличие двух разных признаков с попарно одинаковыми значениями). И решил выполнить проверку: взять сырой трафик CICIDS2017, самому выделить в нём сетевые сессии и сформировать свой датасет. Мой датасет должен был совпасть с датасетом CICIDS2017.

Обрабатываю pcap файл с записанным траффиком своим сниффером, выделяю сессии и признаки, сравниваю с датасетом Thursday-WorkingHours-Morning-WebAttacks.pcap_ISCX.csv, пытаюсь понять и исправить расхождения. Да, расхождения есть.

Подробности поиска ошибок

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

Шаг 3. Сэмплирование против дисбаланса классов

Подготовленная подвыборка WebAttacks является насбалансированной: при общем количестве записей 170366 класс нет атаки объединяет 168186 экземпляров, класс есть атака 2180 экземпляров. Для устранения дисбаланса классов подойдет метод случайного сэмплирования (субдискретизация, undersampling), заключающийся в удалении случайно выбранных экземпляров класса нет атаки. Целевое соотношение количества экземпляров классов нет атаки и есть атака я выбрал 70% / 30%.

Шаг 4. Оценка значимости и отбор признаков

Предварительно из признакового пространства были исключены признаки Flow ID, Source IP, Source Port, Destination IP, Destination Port, Protocol, Timestamp в предположении, что признаки формы (соответствующие статистикам сетевого трафика) являются более значимыми для общего случая. Кроме того, исключаемые признаки адресации могут быть относительно легко подделаны злоумышленником и не должны учитываться при обучении.

Анализ значимости признаков я выполнил с помощью встроенного механизма метода sklearn.ensemble.RandomForestClassifier (атрибут feature_importances_).

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

Итоговые результаты анализа значимости представлены на рисунке ниже, список ограничен первыми двадцатью признаками.

Результаты оценки значимости признаков

Шаг 5. Сокращение признакового пространства

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

Результаты корреляционного анализа двадцати наиболее значимых признаков

Корреляционный анализ показал сильную зависимость между парами признаков:

1. Average Packet Size и Packet Length Mean.

2. Subflow Fwd Bytes и Total Length of Fwd Packets.

3. Fwd Packet Length Mean и Avg Fwd Segment Size.

4. Flow Duration и Fwd IAT Total.

5. Flow Packets/s и Fwd Packets/s.

6. Flow IAT Max и Fwd IAT Max.

По результатам корреляционного анализа из признакового пространства были исключены следующие признаки: Packet Length Mean, Subflow Fwd Bytes, Avg Fwd Segment Size, Fwd IAT Total, Fwd Packets/s, Fwd IAT Max.

После исключения признаков с наименьшей значимостью признаковое пространство было сокращено до объединения 10 признаков:

1. Average Packet Size, средняя длина поля данных пакета TCP/IP (далее длина пакета).

2. Flow Bytes/s, скорость потока данных.

3. Max Packet Length, максимальная длина пакета.

4. Fwd Packet Length Mean, средняя длина переданных в прямом направлении пакетов.

5. Fwd IAT Min, минимальное значение межпакетного интервала (IAT, inter-arrival time) в прямом направлении.

6. Total Length of Fwd Packets, суммарная длина переданных в прямом направлении пакетов.

7. Fwd IAT Std, среднеквадратическое отклонение значения межпакетного интервала в прямом направлении пакетов.

8. Flow IAT Mean, среднее значение межпакетного интервала.

9. Fwd Packet Length Max, максимальная длина переданного в прямом направлении пакета.

10. Fwd Header Length, суммарная длина заголовков переданных в прямом направлении пакетов.

Шаг 6. Выбор модели

На этапе выбора модели я взял 10 наиболее распространенных моделей машинного обучения и оценил их качество на подвыборке WebAttacks.

Список из 10 моделей

Качество ответов классификаторов (моделей) сравнивалось с использованием следующих метрик:

• доля правильных ответов (accuracy);

• точность (precision, насколько можно доверять классификатору);

• полнота (recall, как много объектов класса есть атака определяет классификатор);

• F1-мера (F1-measure, гармоническое среднее между точностью и полнотой).

Оценка качества классификаторов производилась на сбалансированной и предобработанной подвыборке веб-атак WebAttacks набора данных CICIDS2017 (соотношение нормального и аномального трафика 70% / 30%, 20 наиболее значимых признаков). В таблице ниже приведены полученные значения метрик качества, усредненные по результатам 5 итераций кросс-валидации.

Результаты оценки качества десяти классификаторов

Наилучшие результаты ожидаемо продемонстрировали модели (алгоритмы) KNN, CART, RF, AdaBoost, LR. Принимая во внимание минимальное время выполнения, применение модели случайный лес (RF) для решения поставленной задачи является обоснованным выбором.

Исходный код в Google Colaboratory

Шаг 7. Настройка и обучение модели

Итак, за основу я взял модель типа случайный лес, реализация в scikit-learn RandomForestClassifier.

Среди настраиваемых гиперпараметров модели были выбраны следующие: количество деревьев в лесу (n_estimators), минимальное число объектов в одном листе дерева (min_samples_leaf), максимальная глубина дерева (max_depth), максимальное количество признаков для одного дерева (max_features).

Степень квазиоптимальности параметров модели оценивалась значением F1-меры.

Проведенный экспертный анализ я дополнил результатами встроенного метода оптимизации параметров GridSearchCV библиотеки scikit-learn, итоговые значения параметров модели случайный лес получились следующие:

RandomForestClassifier(bootstrap=True, class_weight=None, criterion='gini',max_depth=17, max_features=10, max_leaf_nodes=None,min_impurity_decrease=0.0, min_impurity_split=None,min_samples_leaf=3, min_samples_split=2,min_weight_fraction_leaf=0.0, n_estimators=50,n_jobs=None, oob_score=False, random_state=1, verbose=0,warm_start=False)

Пример настройки

Шаг 8. Тестирование и апробация

Настроенная и обученная модель RandomForestClassifier на тестовой выборке позволила получить оценку полноты (recall) 0.961 и F1-меры 0.971 (запуск 1 в протоколе эксперимента, см. таблицу ниже). Достигнутый результат свидетельствует о возможности повышения точности модели за счет квазиоптимального подбора гиперпараметров (результаты исследования Kahraman Kostas recall 0.94 и F1-мера 0.94, результаты авторов CICIDS2017 recall 0.97 и F1-мера 0.97).

Для апробации модели на реальной сетевой инфраструктуре я разработал свой сетевой анализатор сниффер (C#). Анализатор позволяет перехватить передаваемый сетевой трафик и с использованием алгоритмов реконструкции TCP сессий свободно распространяемых программных продуктов Wireshark и TCP Session Reconstruction Tool выделить отдельные сессии. Для каждой сохраненной сессии сниффер на основе алгоритма CICFlowMeter выделяет признаки и таким образом формирует набор данных.

В качестве атакуемого веб-приложения использовалась разработанная консоль администратора безопасности (PHP) с единственным включенным модулем авторизации, функционирующая под управлением веб-сервера Apache.

Нормальный трафик соответствовал запросам легальных пользователей на подключение к консоли администратора и авторизацию. Вредоносный (аномальный) трафик моделировался программным средством OWASP ZAP и включал три типа атак: Brute Force, XSS, SQL Injection. Соотношение нормального и аномального трафика в реальном тестовом наборе данных составило 70% / 30%.

Схема стенда тестированияПодробно про запуск ZAP

Проведенные эксперименты на сформированном наборе данных (запуски 2, 3 в протоколе эксперимента) показали невозможность применения модели, обученной на наборе данных CICIDS2017, по следующим причинам:

1. Анализ обучающей выборки показывает, что характер моделируемых компьютерных атак в исследовании авторов набора данных CICIDS2017 отличается от реального. Так, атаки типа Brute Force присутствуют в сессиях с максимальными скоростями до 10 Кбит/c, что не соответствует случаям применения автоматизированных средств перебора паролей.

2. Среди десяти признаков с наибольшей значимостью четыре признака Flow Bytes/s (скорость потока данных), Fwd IAT Min (минимальное значение межпакетного интервала в прямом направлении), Flow IAT Std (среднеквадратическое отклонение значения межпакетного интервала), Flow IAT Mean (среднее значение межпакетного интервала) непосредственно зависят от физической структуры сети, в которой производится сбор сетевого трафика, а также настроек сетевого оборудования. В обучающем наборе данных сессии с признаками веб-атак записаны с низкими значениями скорости потока и высокими значениями межпакетных интервалов, что не соответствует характеристикам реальной сетевой инфраструктуры (сеть Ethernet 100 Мбит/c).

Как подготовить свой датасет Протокол эксперимента

Важно. Запуск 2. Модель была обучена на подвыборке WebAttacks набора данных CICIDS2017 (трафик собирался в одной сети). После этого я протестировал модель на реальном трафике в другой сети, отличающейся скоростью и другими характеристиками от первой. И получил неудовлетворительное качество значение F1-меры 0.064.

Оценка вычислительной сложности производилась косвенным способом: разработанный в среде Jupyter Notebook макет системы обнаружения веб-атак запускался на персональном компьютере (процессор Intel Core i5-2300 CPU @ 2300 ГГц, ОЗУ 8 Гб) в режиме обнаружения. Тестовый набор данных содержал около 70000 записанных сессий, время обнаружения составило 0,74669 с. Таким образом, скорость обнаружения веб-атак оценивается величиной порядка 100000 сессий в секунду.

Подведение итогов

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

Настройка параметров выбранного классификатора RandomForestClassifier пакета scikit-learn позволила на тестовой выборке получить оценку полноты (recall) 0.961 и F1-меры 0.971 для набора данных CICIDS2017 и 0.966 и 0.882 соответственно для сформированного в исследовании набора данных.

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

Из отрицательных результатов. Даже с учетом погрешности в оценках качества у меня не получилось применить предобученную модель обнаружения атак в реальной компьютерной сети. Основные причины:

1. Характер моделируемых компьютерных атак при сборе обучающего набора данных отличался от реального.

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

Что исправить, чтобы получилось? Идеально обучать модель на наборе данных, размеченном на основе анализа сетевого трафика в защищаемой сети. При использовании предобученной в другой сети модели (проблема transfer learning) обязательным является соответствие физической структуры защищаемой сети и сети, в которой обучалась модель, а также настроек сетевого оборудования.

Личные выводы. В начале освоения пути исследователя данных применение машинного обучения представлялось в виде 10 строчек кода из примера на scikit-learn.org. Сегодня, глядя на >500 строк кода в итоговом блокноте, я понимаю, сколько еще улучшений можно сделать и как развить решение.

Этот эксперимент занял больше двух лет, без спешки, в перерывах между чтением книг, статей, прохождением курсов, участием в соревнованиях по ML и выступлениями на конференциях. Я был нубом на старте, но смог разобраться и пройти этот увлекательный трек. Впереди новые знания и эксперименты. Но уже сегодня я уверен: современный инженер должен знать, как работает машинное обучение. Чтобы быть ближе к будущему!

Полезные ссылки

Исходный код эксперимента (блокноты, сниффер, разное): github.com/fisher85/ml-cybersecurity

Книги, которые помогли в исследовании:

• Talabis M. Information Security Analytics.

• Sumeet D. Data Mining and Machine Learning in Cybersecurity.

• Lee K.-F. AI Superpowers: China, Silicon Valley, and the New World Order.

• McAfee A. Machine, Platform, Crowd. Harnessing Our Digital Future.

• Chio С. Machine Learning and Security: Protecting Systems with Data and Algorithms.

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

• 2017 год. Курс Введение в машинное обучение от ВШЭ и Yandex.

• 2018 год. Курс Machine Learning Recipes от Google Developers.

• 2019 год. Курс Introduction to Machine Learning for Coders от Fast.ai.

• 2019 год. Курс Practical Deep Learning for Coders от Fast.ai.

• 2020 год. Курс Machine Learning Crash Course от Google Developers.

Цвет титульной фотографии восстановлен здесь

Приветствуем! На протяжении всего времени нашей работы с решениями компании Fortinet, а в частности с межсетевым экраном нового поколения FortiGate, одним из самых интересующих вопросов является контроль и отслеживание трафика отдельных пользователей или групп пользователей. Сегодня мы хотим подробно рассказать о механизме прозрачной аутентификации пользователей на межсетевом экране FortiGate с помощью технологии Fortinet Single Sign-On. Данная статья будет посвящена именно теоретическому аспекту FSSO, поскольку в данном случае без теории тяжело разобраться, что происходит на практике.

Single Sign-On (SSO) - механизм, позволяющий идентифицированным пользователям получать доступ к различным ресурсам в сети без повторной аутентификации. При работе с межсетевым экраном FortiGate, SSO реализуется с помощью FSSO (Fortinet Single Sign On) - комплекса программных агентов, который позволяет устройству FortiGate идентифицировать пользователей сети и тем самым контролировать их доступ к ресурсам сети, а также отслеживать трафик различных пользователей. Когда пользователь аутентифицируется в домене, FSSO агент отправляет на FortiGate имя пользователя, его IP адрес, а также список групп, к которым данный пользователь принадлежит. FortiGate использует данную информацию для того, чтобы разрешить или запретить данному пользователю доступ к сетевым ресурсам. FSSO обычно используется со службами каталогов, такими как Windows Active Directory или Novell eDirectory. Работа FSSO зависит от используемой службы каталогов. В данной статье мы будем рассматривать FSSO для Windows Active Directory (AD).

FSSO для Windows AD использует коллектор агента. Агенты для контроллеров домена (DC агент) также могут использоваться, в зависимости от режима работы коллектор агента. Существует два основных режима работы: DC Agent Mode (режим, в котором используются DC агент) и Polling Mode (в этом режиме используются только коллектор агенты). Также на FortiGate может использоваться Polling режим, который не требует установки сторонних агентов на сервера. Однако, данный вариант подходит только для простых сетей с минимальным количеством пользователей.

Для начала рассмотрим режим DC Agent Mode. Данный режим является рекомендованным для FSSO. Для него требуется:

DC агент, установленный на каждый контроллер домена - если в сети имеется несколько контроллеров домена, агент должен быть установлен на каждый из них;

Коллектор агент - второй компонент FSSO, установленный на сервер Windows, являющийся членом домена. Он собирает события, полученные с агентов для контроллеров домена, и перенаправляет их на FortiGate. Также он отвечает за верификацию групп и проверку рабочих станций на предмет выхода пользователя из системы. Коллектор агент может отсылать на FortiGate информацию о локальных группах безопасности, организационных подразделениях, а также о глобальных группах безопасности. Также коллектор агент можно настроить для выполнения DNS запросов.

Схема работы FSSO в режиме DC Agent Mode представлена на рисунке ниже:

1. При аутентификации пользователя DC агент перехватывает запись о входе на контроллере домена.

2. Затем DC агент выполняет DNS запрос для определения IP адреса пользователя и передает полученную информацию на коллектор.. После того, как коллектор получает информацию, он снова выполняет DNS запрос для того, чтобы определить, был ли изменен IP адрес пользователя.

3. После этого, вся информация о пользователе передается на FortiGate.

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

Перейдем ко второму режиму - Collector Agent-Based Polling Mode. Данный режим не требует установки DC агентов на контроллеры домена. Однако, требования к установке коллектор агентов на сервер или сервера, принадлежащие домену, остаются. В таком случае коллектор агент периодически опрашивает контроллеры домена на предмет наличия событий log-on пользователей. Для этого могут использоваться различные методы:

NetAPI: Агент обращается к временным сессиям, созданным на контроллере домена в момент входа пользователей в домен, и вызывает функцию NetSessionEnum. Данный метод работает быстрее остальных, однако он может пропустить некоторые события входа при высокой нагрузке контроллера домена. Это связано с тем, что при высокой нагрузке сессии могут удаляться из оперативной памяти до того, как агент успеет к ним обратиться и передать информацию на FortiGate.

WinSecLog: Агент обращается ко всем логам событий безопасности в контроллере домена. В таком случае, он не пропустит ни одного события входа пользователя, поскольку логи событий безопасности обычно не удаляются. Однако, при передаче информации на FortiGate возможны задержки - главными причинами являются большой объем сети, а также медленная скорость записи логов. Данный метод является самым распространенным.

WMI: Агент с помощью Windows API получает системную информацию с контроллера домена. Контроллер домена по запросу возвращает все требуемые события входа пользователей в домен. Данный способ позволяет уменьшить нагрузку канала между коллектор агентом и контроллером домена.

Схема работы Collector Agent-Based Polling режима представлена на рисунке ниже:

1. Пользователь аутентифицируется в домене, предоставляя свои учетные данные на контроллер домена;

2. Коллектор агент периодически (раз в несколько секунд) опрашивает контроллер домена на предмет наличия событий входа пользователей в домен;

3. Коллектор агент посылает полученную информацию на FortiGate;

4. Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает данный трафик.

И третий режим, который мы сегодня рассмотрим - Agentless Polling Mode. Процесс его работы схож с предыдущим режимом, однако вместо использования коллектор агента, FortiGate опрашивает контроллер домена самостоятельно. Из-за этого присутствует ряд ограничений:

• Требуется больше системных ресурсов;

• Происходит опрос только двух событий - ID 4768 и ID 4769. Для этого используется протокол SMB;

• Отсутствуют дополнительные возможности, которые можно использовать при наличии коллектор агента, например - проверка конечных станций.

Схема работы данного режима представлена на рисунке ниже.

1. FortiGate опрашивает контроллер домена для получения событий входа пользователей в систему.

2. После аутентификации пользователя на контроллере домена, FortiGate получает это событие во время следующего опроса в совокупности со следующей информацией: имя пользователя, имя машины, IP адрес. Затем, он запрашивает группы пользователей, о которых получил информацию.

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

Подведем итоги, выделив основные отличия в режимах DC Agent Mode и Polling Mode:

FSSO в режиме DC Agent Mode сложнее в инсталяции. Он требует установки коллектор агента, а также DC агента на каждый контроллер домена, в котором мониторятся события входа в систему. Но в то же время этот режим является более масштабируемым, поскольку работа по захвату событий входа реализуется DC агентами, которые и передают данную информацию на коллектор агент.

В Polling Mode коллектору необходимо опрашивать каждый контроллер домена раз в несколько секунд. При увеличении числа контроллеров домена, число запросов также растет. Даже если использовать несколько коллектор агентов - каждый из них должен опрашивать все контроллеры домена самостоятельно.

Также, в режиме DC Agent Mode необходимые события собираются один раз и отправляются на привязанные коллектор агенты. Поэтому, события входа пользователей не упускаются. А в режиме Polling Mode, некоторые события входа могут быть пропущены, или при их передаче может возникнуть задержка.

Для удобства, основные отличия в режимах были сведены в таблицу:

На этом теоретическая часть, посвященная технологии FSSO, закончена. В следующий раз мы осветим именно практические аспекты данной технологии. Чтобы не пропустить новых материалов, следите за новостями на наших каналах:

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал