Современные киберугрозы стали изощрённее и сложнее: вирусы, ботнеты, трояны, DDoS, социальная инженерия, автообзвоны с ИИ, фишинг и прочее. Атаки на сайты и на IT-инфраструктуру компаний могут вестись по разным направлениям, при этом в работе атакующих могут числиться крайне сложные средства автоматизации. Но чем больше атак, тем сложнее анализировать лог событий и принимать своевременное решение об обнаружении киберугрозы. А если факт нарушения нельзя установить, то и система безопасности не может отработать по своему назначению – среагировать и устранить проблему/инцидент.
Ниже наша попытка изложить эффективный алгоритм пайплайна автоматического обнаружения угроз с применением нейросетей, таких как ChatGPT или DeepSeek, LLaMa, и прокси-серверов для работы с Big Data.
Предположим, что у вас есть собственный отдел кибербезопасности. Его работа сводится к тому, что сотрудники будут мониторить события в IT-инфраструктуре, чтобы найти нарушения и вовремя их предотвратить – чтобы исключить или минимизировать последствия в случае эксплуатации уязвимостей или активных атак на сеть предприятия.
Технически, мониторинг киберугроз сводится к изучению данных в логах профильных систем безопасности. Что-то в реальном времени, а что-то – уже после наступления инцидента.
Но человеческий ресурс сильно ограничен: сотрудники буквально не могут изучить мгновенно огромные объёмы информации. А представьте, что у вас на обслуживании сайт с тысячами посетителей в сутки. Просмотр одних только логов доступа будет занимать много-много часов. А значит, чтобы ускорить процесс, нужно либо нанимать ещё специалистов, либо автоматизировать процесс мониторинга угроз.
Человеческие глаза легко могут «проморгать» повторяющиеся паттерны и не найти никаких проблем в безопасности. Автоматические алгоритмы ошибок не допускают.
Большую часть рутинных действий способны автоматизировать профильные системы:
Но они слишком дорогие в приобретении и обслуживании, даже если брать всё на аутсорс в формате готового облака. Плюс часть задач такие системы всё равно не решают – слишком много нюансов может быть внутри конкретного проекта – сайта, сервиса, IT-инфраструктуры.
Более логичный выход для небольших стартапов и компаний – написать свою систему обнаружения угроз – с мониторингом в реальном времени и с интеграцией систем оповещений в нужных форматах (например, через общие или корпоративные мессенджеры).
Как может выглядеть такая система обнаружения атак или угроз с ИИ? Попробуем разобрать кейс ниже.
Наиболее важные компоненты системы мониторинга и обнаружения угроз:
По каждому пункту расскажем чуть-чуть подробнее.
Язык программирования Python подкупает не только простотой синтаксиса и своей интерактивностью (когда запуск кода возможен без предварительной компиляции), но и широким обилием готовых библиотек непосредственно для парсинга, а также для обработки массивов данных.
Да, с Python могут поспорить и другие языки: Go, JavaScript, Java и прочие. Но Python традиционно – лучший выбор для новичков, для него больше всего примеров кода под любые цели и задачи. Встроенный менеджер пакетов pip может работать как с глобальным индексом библиотек, так и с локальной корпоративной библиотекой (задача удобней всего решается с задействованием pip+прокси).
На всякий случай пара рекомендаций: ключи доступа, пароли и другую чувствительную информацию, необходимую для доступа к внешним сервисам (API, прокси), мы рекомендуем хранить на уровне переменных среды. Если вы используете общие хранилища кода, такие как GitHub, ключи и пароли не должны выгружаться на них, даже если хранилище закрытое (приватное). И не забывайте отключать режим отладки перед запуском своих скриптов в продакшн.
Да, на Python парсер легко написать буквально несколькими строками кода. Вот несколько наших предметных примеров: парсинг Google Scholar, простейший TikTok-парсер, извлечение данных из профилей LinkedIn и пр.
Но этого мало. Для работы с данными обязательно потребуются специальные библиотеки и фреймворки. Например, за интеграцию с headless-браузерами или с антидетектами отвечают web-драйверы, такие как Playwright или Selenium. Оба хороши, но у каждого есть свои нюансы применения. «Безголовые» браузеры нужны для выполнения всего JavaScript-кода и получения результирующего HTML. Но они же могут решать ряд других задач, в том числе эмулирование поведения пользователей и уникализация цифровых отпечатков.
Если вам нужно разобрать HTML-код на составляющие, чтобы извлечь из него конкретные данные, то логично задействовать готовый синтаксический анализатор, такой как Beautiful Soup.
Но если вам требуется сложный многопоточный скрейпер, то можно взять за основу готовую реализацию с конвейерами и пауками – фреймворк Scrapy. Он легко и быстро интегрируется с другими библиотеками и сервисами, в том числе с прокси, а также с веб-драйверами и нейросетями.
Обратите внимание: связка из Scrapy + Playwright или Selenium может решать задачи не только с парсингом сайтов (своих или конкурентов). Данные можно извлекать из чего угодно: из файлов, API-интерфейсов, баз данных и т.п. Но наиболее вероятное применение в сфере интернет-безопасности и сборе данных об угрозах – изучение открытых источников с сигнатурами угроз и мониторинг отклонений в вёрстке своих сайтов/web-приложений (для понимания того, что был внедрён зловред).
Чем больше потоков парсинга, тем выше вероятность того, что ваши подключения к целевым ресурсам будут восприниматься как паразитная нагрузка. Соответственно, чтобы обойти ограничения, потребуются прокси. Самые эффективные виды прокси для парсинга – ротируемые, на базе мобильных или домашних IP (резидентные прокси). В некоторых ситуациях вполне могут подойти ротируемые серверные прокси.
Чтобы не писать своих скриптов ротации прокси и не следить за их качеством и доступностью, можно приобрести ротируемые прокси с обратной связью, например, через сервис Froxy.
Такие прокси подключаются в коде один раз (в том числе на уровне переменных среды), а все остальные настройки, касающиеся выбора точки выхода (таргетинга) и ротации, определяются в личном кабинете. В любой момент ненужный прокси-фильтр можно заблокировать или ограничить по объёму потребляемого трафика (чтобы исключить злоупотребления со стороны участников команды).
Froxy – это 10+ млн. IP в 200+ странах с таргетингом до города и оператора связи. Расчёт осуществляется только на основе потребляемого трафика. Ротация прокси осуществляется автоматически (естественным образом, по мере выбывания IP) или по времени.
Самый подробный гайд по парсингу без блокировок
Лучшие прокси-серверы для доступа к ценным данным со всего мира.
Искусственный интеллект (ИИ) вполне может заменить человека в отельных задачах. Особо хорошо нейросети справляются с изучением больших объёмов данных и с поиском повторяющихся паттернов. А именно это от них и требуется в TIP-системах.
Нейросети могут работать на локальном ПК, на вашем сервере (с полноценным API-интерфейсом) или представлять собой готовые web-сервисы.
Нейросети, которые можно установить на своё оборудование: LLaMa, DeepSeek, Mistral, Qwen, Grok (от xAI Илона Маска) и т.п. Они могут развёртываться на основе готовых окружений с единым API и даже с графическими интерфейсами. Это такие решения, как GPT4All, LM Studio и пр. Они же могут выступать посредниками при работе с облачными (SaaS) моделями.
Нейросети, которые работают только в виде готовой SaaS-инфраструктуры: ChatGPT (от OpenAI), Gemini (от Google), Claude GPT (от Anthropic) и прочие.
Технически общение с ИИ из скриптов выглядит максимально просто: отдельным полем передаются вводные инструкции (пожелания, задачи, промт), а отдельным – данные. Если данные не умещаются в один запрос (у каждой модели могут быть свои лимиты по токенам или символам), то применяется разбивка на цепочки.
Нейросеть, которая может работать локально, потребляет немало вычислительных ресурсов, соответственно, для её запуска нужно мощное «железо». Но если вам нужна постоянная доступность, такое «железо» придётся арендовать в формате хостинга. В некоторых ситуациях гораздо логичнее и проще оплатить подписку к готовому API облачных GPT-моделей.
Так как внутри одной системы ИИ-обнаружения угроз может быть задействовано одновременно до нескольких самостоятельных GPT-нейронок (локальные LLM, на своём сервере или удалённо по API), может потребоваться универсальное средство оркестрации.
Примерно такой функционал предоставляет фреймворк LangChain. Он позволяет «общаться» со всеми вашими нейросетями единым унифицированным языком – LCEL. А ещё с LangChain проще разбивать большие объёмы данных на чанки (цепочки). Для LangChain есть плагин быстрого коннекта к моделям, которые кэшируются из HuggingFace (для локального выполнения на устройстве). Плюс LangChain можно тесно интегрировать с LangGraph (фреймворк для обработки графов знаний, применяется для построения своих правил и создания контролируемых агентов на базе сторонних LLM-моделей) и векторными хранилищами (VectorStore).
Тут всё относительно просто: нужно выбрать тот формат хранилища данных, который больше всего подходит вашему проекту с AI-пайплайнами.
SQL-базы больше подходят для оперативной выборки на основе структурированных запросов. А JSON – для отдачи/обмена по API.
Когда данные проанализированы, скрипт может найти сигнатуру. Но что делать с фактом обнаружения угрозы? Логично отправить уведомления тем сотрудникам, которые будут отвечать за устранение конкретной проблемы.
Самый простой вариант оповещений, который можно организовать на своём сервере – отправка email-сообщений (для этого задействуется SMTP-протокол).
Но email не такие оперативные и удобные, как хотелось бы. Более вероятно, что в компании будет использоваться корпоративный или общий мессенджер, такой как Slack, Telegram и т.п. У внешних мессенджеров свой API-интерфейс или механизм обработки web-хуков.
Скрипт при обнаружении угрозы должен уметь отправлять уведомления по тем каналам оповещений, которые вам нужны.
CRON, Prefect и Airflow — это инструменты для автоматизации и управления запуском задач. Они различаются по масштабу, возможностям и уровню абстракции. CRON – это классический планировщик задач, который предустановлен на большинстве Linux-серверов. Он умеет запускать задачи по повторяющимся расписаниям. Из минусов – не умеет отслеживать статусы состояния задач, соответственно, плохо подходит для мониторинга и перезапуска в случае ошибок или проблем.
Airflow — мощный оркестратор задач от Apache, фреймворк для построения, планирования и мониторинга сложных цепочек задач (workflows). Задачи описываются графами DAG на Python. Внутри могут быть зависимости и ветвления. В наличии готовый web-интерфейс для мониторинга состояния тасков и поддержка внешних хранилищ: S3, PostgreSQL, BigQuery и др.
Airflow может быть избыточным и громоздким, но именно он лучше всего подходит для data engineering, ETL-пайплайнов и обработки больших данных.
Prefect – альтернатива Airflow. В наличии более современный API-интерфейс и всё для масштабирования в облачной инфраструктуре. А ещё Prefect поддерживает асинхронность и удобное логирование.
Изложим примерную работу алгоритма по мониторингу киберугроз и рассылки уведомлений в случае их обнаружения.
На этом этапе TIP-система получает входящие данные из различных источников, таких как: GitHub (здесь возможен поиск по ключевым словам в репозиториях и по issues), тематические RSS-ленты, форумы, Telegram-каналы или профильные API threat-репозитории.
Как можно догадаться, под каждый источник потребуется свой отдельный парсер, чтобы извлекать со страниц только те данные, которые потребуются для обнаружения угроз.
Парсинг может работать по простому расписанию в CRON.
Сырые данные с сигнатурами точно будут в неструктурированном виде. Поэтому их требуется очистить (удалить ненужный HTML/CSS/JS-код), разбить на цепочки/чанки (в соответствии с лимитами токенизации), пропустить через языковой фильтр, выделить ключевые сущности и т.п.
Задача — подготовить текст к эффективному анализу ИИ, привести его к единому формату, который удобно подавать в модель. Иначе обнаружение угроз будет невозможно.
Когда у вас есть база сигнатур (знания о том, как можно выявить или обнаружить угрозу), вы можете выдать инструкции LLM. А затем подать на вход данные, которые нужно проанализировать на наличие этих угроз.
Собственно, как раз здесь и происходит вся «магия» ИИ-обнаружения киберугроз.
Стоит отметить, что данные в любом случае отправляются по API, вне зависимости от того, где работает нейросеть – локально или удалённо.
Одним из заданий для ИИ-модели должна быть задача классификации уровня угрозы – на основе идентификаторов IoCs (Indicators of Compromise). Плюс ИИ может параллельно оценить достоверность угрозы и сформулировать краткую сводку для оператора.
Запросы можно кастомизировать — например, использовать цепочки подсказок (prompt chaining) или few-shot-примеры.
Получите максимальную гибкость и бесперебойную связь с мобильными IP-адресами.
Результаты анализа из ИИ передаются в логический модуль принятия решений. Он может действовать по простым правилам:
При необходимости — подключаются дополнительные эвристики или ML-классификаторы.
Здесь формируются отчёты и уведомления. Например:
Внимательно следите за правами доступа к своей TIP-системе. Запускайте парсеры и сборщики данных, ИИ-анализаторы в изолированных средах: Docker, Kubernetes, виртуальные машины. Не давайте внешним сервисам (особенно нейросетям) избыточных прав.
Параметры доступа к прокси, а также токены и другие данные для авторизации храните отдельно от основного кода и не выгружайте в общие хранилища.
По возможности разделяйте компоненты своей системы: сбор данных, анализ, хранение. Они должны работать в разных процессах и на разных портах (а ещё лучше – в разных виртуальных машинах/изолированных средах).
Чтобы сэкономить на токенах при обработке данных в ИИ, предварительно фильтруйте и проверяйте входящие данные. Используйте валидацию, чтобы исключить инъекции, XSS, и другие манипуляции со стороны внешних источников.
Предельно контролируйте выход вызовов наружу. Если ваша платформа отправляет запросы в GPT через OpenAI API или обращается к внешним репозиториям — по максимуму логируйте все запросы. А ещё можно использовать прокси, чтобы ограничить возможные утечки данных или злоупотребления через LLM-интеграции.
Периодически проводите аудит системы и изучайте логи событий. Логи храните отдельно и следите за их ротацией – файлы могут иметь неприлично большой размер, но они крайне важны для анализа инцидентов. Как минимум раз в неделю запускайте проверку на CVE у используемых модулей и Python-библиотек (+следите за апдейтами компонентов).
Не забывайте про лимиты запросов по API (rate-limits) – не выходите за их пределы. А ещё лучше, при разбивке чанков делайте их немного меньше, чем того требует документация, чтобы иметь «запас прочности».
Никогда не забывайте о бэкапах! Все разработчики делятся на две группы: те, кто уже делает резервные копии, и те, кто их ещё пока не делает. В бэкапы точно следует включить базу IoC, метаданные и конфиги. Не забывайте периодически проверять, что данные могут восстанавливаться из архива.
На этом пока всё!