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

• AWS Elastic Disaster Recovery (AWS DRS) минимизирует время простоя и потерю данных благодаря быстрому и надежному восстановлению локальных и облачных приложений с использованием доступного хранилища, минимальных вычислительных ресурсов и восстановления на определенный момент времени.

• Amazon GuardDuty — это служба обнаружения угроз, которая непрерывно отслеживает ваши учетные записи и рабочие нагрузки AWS на предмет вредоносной активности и предоставляет подробные выводы по безопасности для обеспечения видимости и устранения.

• AWS Security Hub — это служба управления безопасностью облака (CSPM), которая выполняет проверки на соответствие лучшим практикам безопасности, агрегирует оповещения и обеспечивает автоматическое устранение.

Архитектура

Описание решения

Решение для сканирования вредоносного ПО предполагает, что локальные серверы уже реплицируются с помощью AWS DRS, а Amazon GuardDuty и AWS Security Hub включены. Стек cdk в этом репозитории развернет только компоненты, помеченные как DRS Malware Scan на диаграмме архитектуры.

1. AWS DRS реплицирует исходные серверы из локальной среды в AWS (или из любого другого облачного провайдера). Для получения дополнительных сведений о настройке AWS DRS следуйте Краткому руководству по началу работы.
2. Amazon GuardDuty уже включена.
3. AWS Security Hub уже включен.
4. Решение для сканирования вредоносного ПО запускается по правилу расписания в Amazon EventBridge (с префиксом DrsMalwareScanStack-ScheduleScanRule). Вы можете настроить частоту сканирования по мере необходимости (например, раз в день, раз в неделю и т. д.).
5. Правило расписания в Amazon EventBridge запускает функцию Lambda Submit Orders (с префиксом DrsMalwareScanStack-SubmitOrders), которая собирает исходные серверы для сканирования из таблицы DynamoDB Source Servers.
6. Заказы помещаются в очередь FIFO SQS с именем Scan Orders (с префиксом DrsMalwareScanStack-ScanOrdersfifo). Очередь используется для сериализации запросов на сканирование, сопоставленных с одним и тем же экземпляром DRS, предотвращая состояние гонки.
7. Функция Lambda Process Order извлекает заказ на сканирование вредоносного ПО из очереди и обогащает его, подготавливая предстоящую операцию сканирования. Например, она вставляет идентификатор реплицирующего экземпляра DRS, связанного с исходным сервером DRS, указанным в заказе. Результатом работы Process Order являются команды сканирования вредоносного ПО, содержащие всю необходимую информацию для вызова сканирования GuardDuty.
8. Операции сканирования вредоносного ПО отслеживаются с помощью DRSVolumeAnnotationsDDBTable на уровне томов, что обеспечивает возможность составления отчетов.
9. Команды сканирования вредоносного ПО помещаются в очередь FIFO SQS Scan Commands (с префиксом DrsMalwareScanStack-ScanCommandsfifo) для повышения отказоустойчивости.
10. Функция Process Commands отправляет команды из очереди с максимальной скоростью 1 команда в секунду, чтобы избежать ограничения API. Она запускает функцию сканирования вредоносного ПО по требованию, предоставляемую Amazon GuardDuty.
11. За выполнением задания Amazon GuardDuty Malware по требованию можно следить из сервиса Amazon GuardDuty.
12. Результат задания по сканированию вредоносного ПО направляется в Amazon CloudWatch Logs.
13. Функция Lambda Subscription Filter получает результат сканирования и отслеживает его с помощью DynamoDB (шаг №14).
14. Таблица DynamoDB DRS Instance Annotations отслеживает статус задания по сканированию вредоносного ПО на уровне экземпляра.
15. Стек CDK с именем ScanReportStack развертывает функцию Lambda Scan Report (с префиксом ScanReportStack-ScanReport) для заполнения Amazon S3 bucket с префиксом scanreportstack-scanreportbucket.
16. AWS Security Hub агрегирует и коррелирует выводы от Amazon GuardDuty.
17. Событие вывода Security Hub перехватывается правилом EventBridge (с префиксом DrsMalwareScanStack-SecurityHubAnnotationsRule).
18. Функция Lambda Security Hub Annotations (с префиксом DrsMalwareScanStack-SecurityHubAnnotation) генерирует дополнительные заметки (аннотации) к выводу с контекстной информацией о затронутом исходном сервере. Эта дополнительная информация видна в разделе Notes в выводе Security Hub.
19. Последующие действия зависят от принятого процесса реагирования на инциденты. Например, на основе даты заражения AWS DRS можно использовать для восстановления на определенный момент времени с использованием снимка, сделанного до даты заражения вредоносным ПО.
20. В сценарии с несколькими учетными записями это решение может быть развернуто непосредственно в учетной записи AWS, где размещается решение AWS DRS. Выводы Amazon GuardDuty будут автоматически отправляться в централизованную учетную запись безопасности.

Использование

Предварительные требования

• Учетная запись AWS.

• Настроенный Amazon Elastic Disaster Recovery (DRS), по крайней мере, с 1 синхронизированным исходным сервером. Если нет, обратитесь к этой документации. Конфигурация репликации должна учитывать шифрование EBS с использованием пользовательского управляемого ключа (CMK) из AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection не поддерживает управляемый ключ AWS по умолчанию для EBS.

• Привилегии IAM для развертывания компонентов этого решения.

• Включенный Amazon GuardDuty. Если нет, обратитесь к этой документации.

• Включенный Amazon Security Hub. Если нет, обратитесь к этой документации.

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

Развертывание

1. Создайте среду Cloud9 с образом Ubuntu (не менее t3.small для лучшей производительности) в вашей учетной записи AWS. Откройте среду Cloud9 и клонируйте код из этого репозитория. Примечание: Amazon Linux 2 имеет node v16, который больше не поддерживается с 2023-09-11.

   root@kitploit:~

   git clone https://github.com/aws-samples/drs-malware-scan
   

   root@kitploit:~

   cd drs-malware-scan
   

   root@kitploit:~

   sh check_loggroup.sh
   

2. Разверните стек CDK, выполнив следующую команду в терминале Cloud9 и подтвердите развертывание.

   root@kitploit:~

   npm install
   

   root@kitploit:~

   cdk bootstrap
   

   root@kitploit:~

   cdk deploy --all
   

   Примечание
   Решение состоит из 2 стеков:

   • DrsMalwareScanStack: развертывает все ресурсы, необходимые для функции сканирования вредоносного ПО. Этот стек обязателен. Если вы хотите развернуть только этот стек, выполните cdk deploy DrsMalwareScanStack.
   • ScanReportStack: развертывает ресурсы, необходимые для отчетности (Amazon Lambda и Amazon S3). Этот стек необязателен. Если вы хотите развернуть только этот стек, выполните cdk deploy ScanReportStack.

   Если вы хотите развернуть оба стека, выполните cdk deploy --all.

Настройка

1. Убедитесь, что исходный сервер(ы) DRS непрерывно реплицируются и находятся в работоспособном состоянии репликации. Это необходимо из-за ограничения в API GuardDuty: на момент написания этой статьи не существует публичного API AWS для сканирования снимков DRS. Единственный способ выполнить сканирование вредоносного ПО на данных исходного сервера(ов) DRS — выполнить сканирование на серверах репликации (экземпляры Amazon EC2), управляемых AWS DRS. Если репликация не выполняется в работоспособном состоянии, ваше сканирование вредоносного ПО DRS может не завершиться успешно. Вы должны подтвердить ReadyforRecovery=Ready.

2. Определите исходные серверы для сканирования. Из всех серверов, реплицируемых с помощью AWS DRS, вам необходимо определить список кандидатов для сканирования. В консоли AWS DRS скопируйте имена исходных серверов, которые вы хотите сканировать с помощью решения, и вставьте их в текстовый редактор. Это будет использовано на следующем шаге.

3. Обновите таблицу DynamoDB. Список серверов для сканирования хранится в таблице DynamoDB, созданной стеком CDK (с префиксом DrsMalwareScanStack-SourceServersDDBTable). Вы должны создать элементы DynamoDB для каждого исходного сервера, реплицируемого с помощью AWS DRS. Для этого перейдите в сервис Amazon DynamoDB и выполните следующие шаги:

4. Запланируйте задание по сканированию вредоносного ПО. Вы можете перейти в сервис Amazon EventBridge и изменить существующее правило, созданное стеком. Отредактируйте правило с префиксом DrsMalwareScanStack-ScheduleScanRule, установите частоту сканирования. Также это правило ПО УМОЛЧАНИЮ ОТКЛЮЧЕНО, пожалуйста, ВКЛЮЧИТЕ его.

5. Проверьте, что Amazon GuardDuty запустил операцию сканирования вредоносного ПО. Чтобы убедиться, что решение работает должным образом, вы можете проверить консоль Amazon GuardDuty -> Malware scans. Через несколько секунд после запланированного времени вы должны увидеть задание со статусом ScanStatus = Running. Если нет, обратитесь к разделу «Устранение неполадок» ниже.

6. Проверьте AWS Security Hub на предмет потенциальных выводов о вредоносном ПО на локальных серверах. Интеграция Amazon GuardDuty с Security Hub позволяет отправлять выводы из GuardDuty в Security Hub.
   • Security Hub отображает только выводы, поэтому задания по сканированию вредоносного ПО с результатом ScanResult=Clean не будут отображаться в консоли Security Hub (только те, у которых ScanResult=Infected).
   • В консоли AWS Security Hub вы можете перейти к выводам и применить фильтр по ProductName=GuardDuty (как показано в анимации ниже).
   • Решение добавляет аннотации в раздел Notes вывода, выделяя имена зараженных локальных серверов.
   • Security Hub интегрирован с Amazon EventBridge для легкой автоматизации реагирования и восстановления, например, отправки электронного письма в SOC, сообщения об инциденте в канале Slack и т. д. Вы можете проверить эту ссылку для получения дополнительной информации.

7. Опционально: Проверьте файл отчета о сканировании вредоносного ПО в S3. Если вы развернули стек ScanReportStack, вы можете запланировать запуск отчета с необходимой вам частотой. Отчет извлечет содержимое таблицы DynamoDB DRSVolumeAnnotationsDDBTable и запишет его в сегмент Amazon S3, созданный стеком (с префиксом scanreportstack-scanreportbucket). Этот отчет перезаписывается (и накапливается) каждый раз при срабатывании правила.

   • Включите правило Amazon EventBridge и установите расписание для запуска отчета: Отредактируйте правило с префиксом ScanReportStack-ScanReportRule, чтобы установить частоту сканирования анализа вредоносного ПО и список исходных серверов DRS для анализа. Кроме того, это правило по умолчанию отключено, пожалуйста, включите его.

          

   • Чтобы проверить отчет, вы можете запросить csv-файл в сегменте Amazon S3 (с префиксом scanreportstack-scanreportbucket).

          

8. Опционально: Для конфигурации с несколькими учетными записями. Если у вас есть выделенная учетная запись безопасности для централизации всех выводов по безопасности в рамках стратегии с несколькими учетными записями, это решение также будет работать. Группа безопасности может выполнять тот же анализ из учетной записи безопасности; выводы Security Hub и GuardDuty, сообщаемые в связанных учетных записях, автоматически копируются в централизованную учетную запись безопасности.

Устранение неполадок

Все функции Lambda направляют журналы в Amazon CloudWatch. Вы можете проверить выполнение каждой функции, проверив соответствующие группы журналов CloudWatch для каждой функции, ищите шаблон /aws/lambda/DrsMalwareScanStack-*.

Продолжительность операции сканирования вредоносного ПО будет зависеть от количества серверов/томов для сканирования (и их размера). Когда Amazon GuardDuty обнаруживает вредоносное ПО, он генерирует вывод Security Hub: решение перехватывает это событие и запускает лямбда-функцию $StackName-SecurityHubAnnotations для дополнения вывода Security Hub заметкой, содержащей имена исходных серверов DRS с вредоносным ПО.

Очереди FIFO SQS можно контролировать с помощью метрик Messages available и Messages in flight из консоли AWS SQS.

Таблицы DynamoDB DRS Volume Annotations отслеживают статус каждой операции сканирования вредоносного ПО.

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

Чтобы проанализировать журналы операций сканирования вредоносного ПО Amazon GuardDuty, вы можете проверить группу журналов Amazon CloudWatch /aws/guardduty/malware-scan-events. Период хранения журналов по умолчанию для этой группы составляет 90 дней, после чего события журнала автоматически удаляются.

Очистка

1. Выполните следующие команды в вашем терминале:

   root@kitploit:~

   cdk destroy --all
   

2. (Опционально) Удалите группы журналов CloudWatch, связанные с функциями Lambda.

Анализ оценки затрат AWS

Для целей этого анализа мы использовали фиктивный сценарий в качестве примера. Следующие оценки затрат основаны на сервисах, расположенных в регионе Северная Виргиния (us-east-1).

Предполагаемый сценарий:

• 2 исходных сервера для репликации (DR) (Общий объем: 100 ГБ - 4 диска)
• 3 ТБ сканируется на вредоносное ПО в месяц
• 30-дневный срок хранения снимков EBS
• Ежедневное сканирование на вредоносное ПО

Разбивка по сервисам:

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

Безопасность

См. CONTRIBUTING для получения дополнительной информации.

Авторы

• Rodrigo Monge
• Thierry Francois
• Diego Pérez Holguín
• Leandro Santi

Лицензия

Этот образец кода лицензирован в соответствии с лицензией MIT-0. См. файл LICENSE.