AWS: Журналы потоков VPC — обзор и пример с помощью CloudWatch Logs Insights

AWS: Журналы потоков VPC — обзор и пример с помощью CloudWatch Logs Insights

AWS VPC Flow Logs позволяет регистрировать информацию о трафике между сетевыми интерфейсами в VPC. Кроме того, эти журналы могут храниться в AWS S3 или отправляться в AWS CloudWatch Logs, при этом включение регистрации трафика никак не влияет на производительность сетевого интерфейса.

Давайте кратко рассмотрим основные понятия, доступные настройки и настроим Flow Logs для VPC с передачей данных для анализа в CloduWatch Logs.

• Обзор VPC Flow Logs
• Случаи использования журналов VPC Flow Logs
• Запись журнала потока — поля
• Ограничения журналов VPC Flow Logs
• Создание журнала VPC Flow Log
• Группа журналов CloudWatch
• Политика IAM и роль IAM
• VPC — включение журналов потоков
• CloudWatch Logs Insights
• Журнал VPC Flow Log — пользовательский формат
• Пользовательский формат журнала Flow Log и CloudWatch Logs Insights
• Примеры Logs Insights
• Полезные ссылки
• Журналы потоков VPC
• Журналы CloudWatch

Обзор журналов VPC Flow Logs

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

Службы, для которых можно использовать журналы Flow Logs:

• Эластичная балансировка нагрузки
• Amazon RDS
• Amazon ElastiCache
• Amazon Redshift
• Amazon WorkSpaces
• NAT-шлюзы
• Транзитные шлюзы

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

Варианты использования журналов потоков VPC

Что можно отслеживать с помощью журналов потока?

• Правила SecuirtyGroup/Network Access List — заблокированные запросы будут помечены как REJECTED
• для чего мы используем журналы — для получения картины трафика между VPC и сервисами, чтобы понять, кто потребляет больше всего трафика, где и сколько кросс-АЗ трафика и так далее
• мониторинг удаленных входов в систему — мониторинг портов 22 (SSH), 3389 (RDP)
• отслеживание сканирования портов

Запись журнала потока — поля

Каждая запись в журнале представляет собой данные об IP-трафике, полученном за интервал агрегации, и представляет собой строку с полями, разделенными пробелами, где каждое поле содержит информацию о передаче данных, например — Source IP, Destination IP, и протокол.

По умолчанию используется следующий формат:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Смотрите таблицу Доступные поля в документации, все, что находится в колонке Версия 2, включено в формат по умолчанию.

При создании журналов Flow Logs мы можем использовать формат по умолчанию или создать свой собственный — мы рассмотрим его ниже:

Ограничения журналов VPC Flow Logs

• нельзя использовать с экземплярами EC2-Classic
• нельзя создавать журналы для пирингов VPC, если они ведут к VPC другой учетной записи
• после создания журнала нельзя изменить его конфигурацию или формат записей.

Также имейте в виду, что

• записи на Amazon DNS не регистрируются, но записываются, если используется ваш собственный DNS
• трафик на и с адреса 169.254.169.254 для получения метаданных экземпляра EC2 не регистрируется
• трафик между сетевым интерфейсом EC2 и интерфейсом AWS Network Load Balancer не регистрируется.

См. все ограничения в разделе Ограничения журнала потока.

Создание журнала потока VPC

Чтобы создать журнал Flow Log, нам нужно указать:

• ресурс(ы), чьи журналы мы будем записывать — VPC, подсеть или конкретный сетевой интерфейс
• тип трафика, который мы будем регистрировать (принятый трафик, отклоненный трафик или весь трафик)
• и куда мы будем записывать данные — в ведро S3 или в журналы CloudWatch.

Пока что давайте посмотрим, что происходит в журналах CloudWatch, а в следующий раз попробуем визуализировать в Kibana.

Группа журналов CloudWatch Logs

Создайте группу журналов:

IAM-политика и IAM-роль

Для того чтобы служба Flow Logs могла писать в наш CloudWatch, нам нужно настроить ее права доступа.

Перейдите в AWS IAM и создайте IAM Policy и IAM Role.

Начните с IAM-политики:

Добавьте правила:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Сохранить:

Теперь создайте роль IAM.

Перейдите в IAM Roles, создайте новую, тип EC2:

Найдите политику, которую мы создали выше, и прикрепите ее:

Задайте ее имя, сохраните:

Перейдите в отношение Role Trust (см. AWS: IAM AssumeRole — описание, примеры), отредактируйте его — для поля Service установите vpc-flow-logs.amazonaws.com:

Установить:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Сохранить:

VPC — включение журналов потоков

И, наконец, перейдите в VPC для включения журналов — нажмите на Flow Logs > Create:

Задайте его имя, Фильтр, Интервал:

В Destination выберите CloudWatch Logs, укажите Log Group и IAM Role:

Format — оставьте Default.

Проверьте статус:

И через пару минут мы увидим наши данные:

В группе Log Group вы можете найти первый поток, названный по интерфейсу Elastic Network Interface, откуда берутся данные:

CloudWatch Logs Insights

Давайте взглянем на CloudWatch Logs Insights.

Щелкните на Queries, чтобы получить некоторые подсказки:

Например, чтобы найти топ-15 хостов, которые обслужили больше всего пакетов:

Или по объему переданных данных:

stats sum(bytes) as BytesSent by srcAddr, dstAddr
| sort BytesSent desc

Хорошо, это хорошо. Но как насчет других форм?

Например, я хотел бы видеть направление запросов (egress/ingress), а также значение поля pkt-dstaddr.

Журнал потока VPC — пользовательский формат

См. подробнее примеры записей журнала Flow.

На данный момент мы можем установить следующий формат:

region vpc-id az-id subnet-id instance-id interface-id flow-direction srcaddr dstaddr srcport dstport pkt-srcaddr pkt-dstaddr pkt-src-aws-service pkt-dst-aws-service traffic-path packets bytes action

В журнале CloudWatch Logs создайте новую группу журналов, назовите ее bttrm-eks-dev-1-21-vpc-fl-custom, не забудьте о сохранении:

Вернитесь в VPC, создайте новый Flow Log и назовите его bttrm-eks-dev-1-21-vpc-fl-custom:

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

Т.е. если первым полем будет «регион» — то и в итоговом журнале оно будет установлено первым:

И результат:

${region} ${vpc-id} ${az-id} ${subnet-id} ${instance-id} ${interface-id} ${flow-direction} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${pkt-srcaddr} ${pkt-dstaddr} ${pkt-src-aws-service} ${pkt-dst-aws-service} ${traffic-path} ${packets} ${bytes} ${action}

Пользовательский формат журнала Flow Log и CloudWatch Logs Insights

Но если мы сейчас перейдем в CloudWatch Logs Insights и попробуем выполнить любой запрос, который использовался ранее, мы не получим поля, которые мы установили.

Итак, мы видим данные, но как мы можем разделить их на поля?

В нашем проекте, я не думаю, что мы будем часто использовать CloudWatch Logs, скорее всего данные будут отправляться в ведро S3, а затем на (logz.io), поэтому я не буду углубляться в детали, но давайте посмотрим принцип работы — он пригодится позже при работе с ELK.

CloudWatch Logs по умолчанию создает несколько мета-полей, которые мы можем использовать в запросах:

Чтобы Custom format увидел поля, нам нужно использовать parse и передать ему @message, чтобы он разобрал содержимое по указанным нами полям:

parse @message "* * * * * * * * * * * * * * * * * * *" 
| as region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action 
| sort start desc

Здесь количество звездочек «*» в @message должно быть таким же, сколько полей мы задали — ${vpc-id} и т.д.

Также имена полей не должны содержать тире. Т.е. имя ${vpc-id} мы должны употреблять как vpc_id (или vpcID — как вам больше нравится).

Проверьте:

Вау! Теперь у нас есть все наши поля.

Помимо разбора, мы можем использовать filter, display, stats. Смотрите все в синтаксисе запросов в CloudWatch Logs Insights.

Примеры Logs Insights

И давайте попробуем сделать пару запросов, например, чтобы получить все запросы, которые были заблокированы SecuirtyGroup/Network Access List — они будут помечены как REJECTED.

Возьмем наш предыдущий запрос:

parse @message "* * * * * * * * * * * * * * * * * * * * * *" 
| as start, end, region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, protocol, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action

И добавим сюда:

• filter action="REJECT"
• stats count(action) as redjects by srcaddr
• sort redjects desc

здесь:

• фильтровать по действию, примененному к пакету — выбрать все REJECTED
• подсчитывать количество событий по примененному действию, выбирая по IP-адресу источника, и выводить в столбце _redjects _
• и отсортировать по redjects.

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

parse @message "* * * * * * * * * * * * * * * * * * *" 
| as region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action 
| filter action="REJECT" 
| stats count(action) as redjects by srcaddr 
| sort redjects desc

И его результат:

Мы также можем использовать отрицательные фильтры и комбинировать их с операторами и/или.

Например, чтобы убрать из вывода все IP, начинающиеся с 162.142.125 — добавьте фильтр filter (srcaddr not like "162.142.125."):

...
| filter action="REJECT"
| filter (srcaddr not like "162.142.125.")
| stats count(action) as redjects by srcaddr
| sort redjects desc

См. примеры запросов.

И добавьте фильтр для выбора только входящих запросов — flow_direction == ingress:

...
| filter action="REJECT"
| filter (srcaddr not like "162.142.125.") and (flow_direction like "ingress")
| stats count(action) as redjects by flow_direction, srcaddr, dstaddr, pkt_srcaddr, pkt_dstaddr
| sort redjects desc

Теперь мы получили топ отклоненных запросов, когда сработало правило SecurityGroup или VPC Network Access List.

И давайте проверим, какой IP указан в dstaddr — кто был конечным пунктом назначения?

Перейдите в E_C2 > Network Interfaces_, найдите по Private IP:

Найдите «Elastic IP address owner»:

ОК, это один из балансиров нагрузки.

Если IP не может быть найден в AWS, это может быть конечная точка Kubernetes, проверьте ее с помощью:

kubectl get endpoints — all-namespaces | grep 10.1.55.140

dev-ios-check-translation-ns ios-check-translation-backend-svc 10.1.55.140:3000 58d

dev-ios-check-translation-ns ios-check-translation-frontend-svc 10.1.55.140:80 58d

Вот, собственно, и все.

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

Журналы потоков VPC

• Сбор журналов потоков Amazon VPC с помощью Elastic Agent — поля и прочее для Кибаны.
• Примеры записей журнала потоков

Журналы CloudWatch

• Основы ведения журналов безопасности AWS — журналы потоков VPC — пример журналов Cloudwatch с Athena
• Анализ запросов и визуализация журналов AWS Cloudwatch с помощью Logs Insight — прмиеры запросов в журналах Cloudwatch
• Как визуализировать и уточнить безопасность вашей сети, добавив идентификаторы групп безопасности в журналы потоков VPC
• Визуализация данных журналов в виде графиков
• Анализируйте журналы CloudWatch как профессионал
• Фильтр, разбор и группировка данных журналов в AWS CloudWatch Logs Insights
• Как анализировать пользовательские журналы VPC Flow Logs с помощью CloudWatch Logs Insights? - ещё примеры с логами и выборками в Инсайтах
• Как я могу использовать запросы CloudWatch Logs Insights с журналом потока VPC?
• Синтаксис запросов CloudWatch Logs Insights
• Поиск проблем с сетями с помощью AWS CloudWatch Logs Insights

Первоначально опубликовано на RTFM: Linux, DevOps и системное администрирование.