Объективы SQL для вашей системы обнаружения вторжений

Объективы SQL для вашей системы обнаружения вторжений

В течение последнего десятилетия приложения работали с данными с высокой пропускной способностью почти в реальном времени. Возьмем, к примеру, системы обнаружения сетевых вторжений (NIDS); важный инструмент сетевой безопасности - независимо от вашего определения безопасности. Еще несколько лет назад такие системы требовали дорогостоящих проприетарных аппаратных решений, связанных с программными инструментами поставщиков оборудования, зачастую плохими. С появлением дешевого и мощного оборудования и сетевых решений с открытым исходным кодом NIDS стала доступна организациям любого размера; направьте свой трафик через маршрутизатор под управлением Linux, затем используйте такой инструмент, как программно-определяемая сеть MantisNet для захвата трафика и, наконец, отправьте данные в высокопроизводительную потоковую структуру, такую ​​как Kafka, где вы можете использовать чрезвычайно масштабируемый SQL для анализировать и вовремя реагировать на угрозы с помощью Lens.

Непрерывные SQL-запросы к потоковой передаче данных с помощью Lenses ® могут легко позволить нам создать нашу собственную систему обнаружения вторжений (IDS). Но прежде чем приступить к написанию правильного SQL, чтобы начать обнаружение вторжений, нам нужно понять, что именно такое IDS.

Что такое IDS?

Система обнаружения вторжений (IDS) - это система, которая отслеживает сетевой трафик на предмет подозрительной активности и выдает предупреждения при обнаружении такой активности. Хотя обнаружение аномалий и составление отчетов являются основной функцией, некоторые системы обнаружения вторжений способны предпринимать действия при обнаружении вредоносной активности или аномального трафика, включая блокировку трафика, отправляемого с подозрительных IP-адресов.

Различные типы IDS?

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

• Обнаружение сетевых вторжений (NIDS)
• Обнаружение вторжений на хост (HIDS)
• Обнаружение вторжений на основе сигнатур
• Обнаружение вторжений на основе аномалий

Системы обнаружения вторжений были разделены на следующие категории:

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

В этом посте мы рассмотрим случай пассивной IDS и, в основном, методы обнаружения NIDS и аномалий.

Линзы SQL

Чтобы продемонстрировать возможности непрерывных SQL-запросов через Lenses и параллельно построить простую IDS, мы сосредоточимся на DNS-трафике и его различных уязвимостях.

Захват DNS-трафика

MantisNet предоставляет отличный образ докера, который захватывает весь трафик для DNS и DHCP. Параллельно он может отправлять все данные в тему Kafka. Как только данные представлены в теме, вы можете использовать SQL-запросы в Lenses для создания пассивной IDS, применяя методы обнаружения NIDS и аномалий. Требуемый код SQL довольно прост.

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

Запустите сборщик DNS MantisNet

MantisNet собирает данные, но для обработки их необходимо отправить в Kafka, чтобы они были обработаны, как только они станут доступны. Теперь вам нужно настроить сборщик DNS для отправки данных в тему Kafka.

Во-первых, вам нужно запустить сборщик DNS с помощью следующей команды:

Проверка DNS

Правило №1 - проверка длины DNS

Типичный запрос DNS в IPv4 - это полезная нагрузка UDP размером 512 байт для передачи сообщений DNS. Мы можем создать непрерывный SQL-запрос, чтобы найти все запросы, превышающие это число, как нарушение протокола DNS.

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

Вы закончили, вы только что создали свое самое первое правило IDS о проверке полезной нагрузки UDP длины DNS.

Давайте поясним, что это всего лишь пример запроса проверки DNS, и если мы хотим расширить это правило, чтобы сделать его более точным, мы должны принять во внимание другие данные, например, если сервер и клиент поддерживают EDNS или если это задача для зональные передачи, которые оба могут использовать большие полезные нагрузки. Поддержка больших объемов данных через UDP не рекомендуется. В этом случае вы можете столкнуться с атаками усиления с использованием серверов имен.

DNS-туннелирование

DNS никогда не предназначался для передачи данных, однако он использовался для этой цели лицами со злым умыслом в течение многих лет.

DNS как туннель может быть установлен при сокрытии данных (в URL-адресах в кодировке base64) внутри DNS-запросов, которые затем могут быть преобразованы в реальные данные на целевом DNS-сервере. Это может превратиться в реальную угрозу, когда вредоносное программное обеспечение использует DNS для получения данных из сети компании или даже для получения команд / обновлений от сервера управления и контроля.

DNS использует иерархическую систему для определения правильного IP-адреса для домена, как показано на следующем изображении:

Итак, в приведенном выше примере вместо разрешения blog.landoop.com мы могли бы отправить другой запрос:

Fi0tYwluPWxvA5JoeXmoBGt2a2VyPXRlc3Q7cGFzc3dvcmC9VBNzNDU=.landoop.com

Этот запрос будет отправлен в домен landoop.com. Разница в том, что строка перед landoop.com закодирована в base64 и будет декодирована в

“domain=landoop;user=spiros;password=123456” 

Как вы понимаете, использовать DNS для передачи данных очень просто.

Правило №1 - Длина имени URL-адреса запроса

Типичный DNS-запрос не такой длинный, например, google.com, mail.google.com, landoop.com, blog.landoop.com и т. Д. При использовании DNS-туннелирования длина символа URL-запроса выше. Предыдущий пример иллюстрирует это. Если в запросе содержится больше информации, запрос может легко преодолеть барьер в 70 символов. Это довольно необычный запрос на доменное имя. Мы можем создать непрерывный запрос линз, чтобы найти все запросы, превышающие это число, как угрозу туннелирования DNS.

Мы начинаем с группирования записей в реальном времени по «Исходному адресу» и «URL-адресу», чтобы сохранить уникальные DNS-сообщения для одного и того же хоста и одного и того же URL-адреса. Запрос отфильтровывает те записи, в которых длина URL-запроса превышает 60 символов. Вы можете увидеть правило в объективах как потоковая топология:

Минимальную длину URL-адреса можно настроить в соответствии с вашей средой и вашими случаями. Вы можете начать с низкого (~ 50) и увеличить его, если вы получите много ложных срабатываний.

Правило # 2 - Схема запросов

Еще одно правило DNS-туннелирования - проверка количества чисел, включенных в URL-адрес. Типичный URL-адрес не состоит из большого количества цифр. Но когда данные кодируются с использованием base64 (группа подобных схем двоичного кодирования в текст, которые представляют двоичные данные в строковом формате ASCII, переводя их в представление radix -64), URL потенциально может состоять из много чисел, поэтому мы можем использовать это для обнаружения потенциального туннелирования DNS.

Это правило проверяет все запросы DNS и определяет, состоит ли URL-адрес более чем из 4 чисел, и параллельно оно безопасно исключает запросы DNS, состоящие из IP-адресов, которые обычно содержат более 4 чисел. Конечно, это число можно настроить в соответствии с вашей средой. Кроме того, сопоставление регулярных выражений - дорогостоящая операция, но LSQL можно линейно масштабировать с помощью Connect или Kubernetes. Вы можете увидеть правило в объективах как топология потока:

Что дальше

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

Помимо вышеперечисленного, Lenses SQL помогает вам быстро определять подозрительный сетевой трафик, вы в небольшом шаге от создания панели оповещений в реальном времени. Платформа Lenses предоставляет библиотеку Javascript (промежуточное ПО Redux), позволяющую подключаться к оповещениям в реальном времени.

Заключение

Как вы понимаете, применение IDS для больших и многомерных потоков данных - сложная задача. Потоки данных имеют характеристики, совершенно отличные от характеристик статистических баз данных, что сильно влияет на производительность алгоритмов идентификации на основе аномалий, используемых в процессе обнаружения. Эти характеристики включают, помимо прочего, обработку больших объемов данных по мере их поступления (в реальном времени), динамический характер потоков данных, проклятие размерности, ограниченный объем памяти и высокую сложность. К счастью, Lenses SQL Engine может линейно масштабировать этап обработки с помощью Connect или Kubernetes. Таким образом, инженеры по обработке данных и безопасности могут сосредоточиться на реальной проблеме, которая в данном случае заключается в обеспечении безопасности своих систем.

Посетите документацию по Lenses, чтобы узнать больше о Lenses SQL Engine.