Ведение журнала SSH и управление сеансами с помощью AWS SSM

Опубликовано: 2022-03-11

Настройка пользовательских инструментов или сценариев для ведения журнала SSH в Linux может быть утомительной и подверженной ошибкам.

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

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

  • ЕС2
  • IAM (управление идентификацией и доступом)
  • KMS (служба управления ключами)
  • Журналы CloudWatch (и/или S3)
  • AWS Systems Manager (ранее известный как SSM)

Давайте посмотрим, как настроить каждый из них.

EC2 и IAM

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

Роль IAM, которую мы связываем с нашим инстансом EC2, должна иметь встроенную политику AmazonSSMManagedInstanceCore , а также эту политику (прикрепленную как встроенную или управляемую клиентом):

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

Помимо роли IAM, мы обычно используем следующую конфигурацию экземпляра EC2:

  • Операционная система — Amazon Linux 2, поскольку по умолчанию она поставляется с установленным агентом AWS Systems Manager (агентом SSM). (Так же как и дистрибутивы Ubuntu, которые также являются опцией.)
  • Тип экземпляра — t3.micro (но подойдет любой тип).
  • Группа безопасности по умолчанию, которую AWS назначает VPC, будет работать, так как нам не нужен открытый порт SSH для этого упражнения.

Мы можем приступить к настройке KMS, не дожидаясь загрузки инстанса EC2.

КМС

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

Скриншот AWS с навигационными цепочками «KMS», «Ключи, управляемые клиентом» и «Создать ключ» на этапе 1: «Настроить ключ». «Тип ключа» может быть установлен на «Симметричный» (выбрано) или «Асимметричный». В разделе «Дополнительные параметры» параметр «Происхождение материала ключа» может быть «KMS» (выбрано), «Внешнее» или «Пользовательское хранилище ключей (CloudHSM)».
Шаг 1: Выбор типа симметричного ключа.

Скриншот AWS с теми же хлебными крошками, теперь на шаге 2: «Добавить метки». В поле «Псевдоним» установлено значение «cwlg», необязательное поле «Описание» остается пустым, а в необязательное поле «Теги» теги не добавляются.
Шаг 2: Именование нашего ключа.

Скриншот AWS с теми же навигационными цепочками, теперь на шаге 3: «Определить ключевые административные разрешения». В первом поле «Ключевые администраторы» есть пустое поле поиска с 10 строками результатов (страница 1 из 3) со столбцами «Имя», «Путь» и «Тип». Только первая строка (с соответствующими значениями столбцов «admin», «/» и «User») имеет соответствующий флажок. В другом поле «Удаление ключа» есть единственная опция «Разрешить администраторам ключей удалять этот ключ», для которой также установлен флажок.
Шаг 3 (необязательно): Назначение администратора.

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

Здесь мы выбрали пользователя IAM «admin» в качестве главного администратора, но мы можем выбрать любого пользователя или роль. Мы также можем отключить разрешение на удаление ключа для администратора.

Скриншот AWS с теми же хлебными крошками, теперь на шаге 4: «Определить разрешения на использование ключей». Первое поле «Эта учетная запись» имеет те же результаты поиска, что и на шаге 3, но ни одно из них не отмечено флажком. В другое поле «Другие учетные записи AWS» ничего не добавлено.
Шаг 4: Пропуск страницы назначения пользователя.

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

Скриншот AWS с теми же панировочными сухарями, теперь на шаге 5: «Проверка». В первом поле «Конфигурация ключа» для параметра «Тип ключа» указано значение «Симметричный», для параметра «Спецификация ключа» указано значение «SYMMETRIC_DEFAULT», для параметра «Использование ключа» указано значение «Шифровать и расшифровать», а для параметра «Происхождение» указано значение «AWS_KMS». ." В следующем поле «Псевдоним и описание» указан один псевдоним «cwlg» без описания. В следующем поле «Теги» данных нет. Последнее поле «Ключевая политика» содержит текстовое поле, предварительно заполненное политикой в ​​формате JSON.
Шаг 5: Просмотрите нашу конфигурацию и поменяйте политику ключей по умолчанию.

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

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Обязательно замените все заполнители:

  • ACCOUNT_ID становится идентификатором нашей учетной записи AWS.
  • USERNAME становится именем пользователя администратора, выбранным на шаге 3. Если мы отказались от этого шага, здесь мы удаляем второй блок операторов (тот, что с "Sid": "Allow access for Key Administrators" ).
  • REGION становится кодом регионального идентификатора, в котором мы развертываем сервисы (например, us-west-1 ).

После этого KMS готов к работе.

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

Затем нам нужна группа журналов CloudWatch (и/или корзина S3 — см. ниже), куда агент SSM может отправлять журналы сеансов SSH. Давайте создадим его.

Скриншот AWS с навигационными цепочками «CloudWatch», «Журналы CloudWatch», «Группы журналов» и «Создать группу журналов». Нет многоступенчатой ​​боковой панели. Первое поле, «Сведения о группе журнала», имеет три подполя: «Имя группы журнала» (установите значение «ssm-session-demo»), «Настройка хранения» (установите значение «Никогда не истекать» в раскрывающемся списке) и «ARN ключа KMS — необязательный» (установлено усеченное значение, начинающееся с «arn:aws:kms»). Второе поле «Теги» не имеет тегов.
Создание группы журналов CloudWatch Logs.

Обратите внимание на поле ARN ключа KMS: AWS предоставляет нам необходимое здесь значение после создания ключа на шаге 5 раздела KMS.

(Если мы не связали правильную политику с нашим ключом KMS ранее, разрешив службе журналов CloudWatch использовать ключ, на этом этапе мы получим сообщение об ошибке, связанное с ключом KMS.)

Хранение журналов SSH в корзине S3

Для хранения журналов активности с помощью S3 вместо журналов CloudWatch или в дополнение к ним нам необходимо добавить эти разрешения в наш профиль экземпляра EC2 в виде отдельной политики (или вручную объединить их с другими разрешениями, которые нам могут понадобиться):

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

В приведенном выше фрагменте обязательно замените заполнитель BUCKET_NAME .

Теперь, когда мы настроили место для хранения журналов — журналы CloudWatch, корзину S3 или и то, и другое — мы готовы подключиться к сеансам SSH.

Диспетчер сеансов AWS Systems Manager

Это последний ключевой шаг, на котором мы настраиваем безопасный доступ к нашей машине Linux для мониторинга и ведения журнала сеансов SSH. Мы начнем с панели управления Session Manager.

Скриншот панели управления AWS Session Manager с разделами «Как это работает», «Зачем использовать Session Manager?», «Приступая к работе», «Дополнительные ресурсы» и в правом верхнем углу «Начать сеанс». В последнем разделе есть оранжевая кнопка «Начать сеанс» и белая кнопка «Настроить настройки».
Шаг 1: Начало работы с приборной панелью.

На панели инструментов нажмите белую кнопку «Настроить настройки» в правом верхнем углу «Начать сеанс», чтобы включить ведение журнала сеанса.

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

Скриншот раздела AWS под названием «Ведение журнала CloudWatch». Его первый параметр, также называемый «Ведение журнала CloudWatch», имеет флажок «Включить», который установлен. В следующем параметре «Выберите предпочтительный вариант ведения журнала» вместо «Загружать журналы сеансов» выбрано «Потоковые журналы сеансов (рекомендуется)». В следующем параметре «Принудительно шифровать» установлен флажок «Разрешить только зашифрованные группы журналов CloudWatch». В последнем параметре «Группа журналов CloudWatch» вместо «Введите группу журналов в текстовом поле» выбрано «Выберите имя группы журналов из списка». Под ним находится список «Группы журналов CloudWatch» с выбранным «ssm-session-demo». Он имеет соответствующие столбцы «Шифрование» (установлено «Зашифровано»), «Срок действия событий после» (установлено «Никогда не истекает»), «Фильтры метрик» (установлено 0), «Сохраненные байты» (установлено 0) и временная метка «Время создания».
Шаг 2a. Включение ведения журнала CloudWatch.

Сразу после раздела «Ведение журнала CloudWatch» есть раздел «Ведение журнала S3», где мы можем выбрать корзину.

Скриншот раздела AWS под названием «Ведение журнала S3». Его первый параметр «Отправлять журналы сеансов на S3» имеет флажок «Включить», который отмечен. В следующем параметре «Принудительное шифрование» установлен флажок «Разрешить только зашифрованные корзины S3». В следующем параметре «Выбрать корзину S3» вместо «Введите имя корзины в текстовом поле» выбрано «Выберите имя корзины из списка». Ниже из раскрывающегося списка выбирается «ssm-session-demo». Последнее поле «Префикс ключа S3 — необязательный» пусто.
Шаг 2b: Включение ведения журнала S3.

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

Итак, начинаем сеанс. На той же странице мы найдем вкладку «Сеансы», где мы можем начать сеанс. Нажав кнопку «Начать сеанс», мы получим список машин EC2, на которых мы можем инициировать сеанс:

Скриншот AWS с навигационными цепочками AWS Systems Manager, Session Manager и Start a session. Поле поиска «Целевые экземпляры» не имеет заполненного запроса и имеет только один результат, где для параметра «Имя экземпляра» задано значение «Демонстрация SSM».
Шаг 3: Выбор нашего экземпляра EC2 для начала сеанса SSH.

Если мы не видим наш инстанс EC2 Linux в списке, мы должны проверить, находится ли он в рабочем состоянии и есть ли связанные с ним разрешения IAM, которые мы описали ранее.

Обработка ошибки агента SSM «Не поддерживает журналы потоковой передачи»

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

Скриншот сообщения об ошибке AWS с белым текстом на красном фоне. X рядом с сообщением «Версия агента SSM, установленная на этом экземпляре, не поддерживает потоковую передачу журналов в CloudWatch. Обновите агент SSM до последней версии или отключите параметр потоковой передачи журналов в настройках».
Потенциальная ошибка «устаревшая версия агента SSM».

Чтобы обновить агент SSM, нам нужно перейти к команде «Выполнить» на левой панели сервиса AWS Systems Manager .

Скриншот панели управления Run Command AWS Systems Manager с разделами «Как это работает», «Функции и преимущества», «Случаи использования и публикации в блогах», «Документация» и в правом верхнем углу «Управление экземплярами». Этот раздел содержит только оранжевую кнопку «Выполнить команду».
Шаг 1: Начнем с панели управления «Выполнить команду».

Оказавшись там, мы можем нажать оранжевую кнопку «Выполнить команду», что приведет к новой странице, где мы можем заполнить некоторые параметры.

Скриншот AWS с навигационными цепочками AWS Systems Manager, Run Command и Run a command. В поле поиска с надписью «Командный документ» перечислены 10 строк (страница 4 из более чем 5), выбрана одна с именем «AWS-UpdateSSMAgent». В столбце «Владелец» указано «Amazon», а в столбце «Типы платформ» — «Windows, Linux». Поле внизу «Версия документа» имеет значение «1 (по умолчанию)», выбранное из раскрывающегося списка.
Шаг 2: Выбор командного документа.

Мы начнем с выбора AWS-UpdateSSMAgent из списка.

Скриншот раздела AWS под названием «Цели». В первом поле, также называемом «Цели», есть параметры «Указать теги экземпляра», «Выбрать экземпляры вручную» (выбрано) и «Выбрать группу ресурсов». Внизу находится окно поиска «Экземпляры» без запроса, с отмеченным единственным результатом «SSM Demo». Соответствующий идентификатор экземпляра в строке копируется в поле чуть выше «Экземпляры» со знаком X.
Шаг 3: Выбор инстанса EC2, для которого требуется обновление агента SSM.

Как только это будет выбрано, мы будем прокручивать вниз, пока не увидим раздел «Цели». Там нам нужно выбрать экземпляр EC2, на котором мы хотим обновить агент SSM, а затем нажать кнопку «Выполнить» в конце. Это отправит нас на страницу, где мы сможем следить за ходом обновления.

Скриншот AWS с навигационными цепочками «AWS Systems Manager», «Выполнить команду» и «Идентификатор команды» (за которым следует GUID). В первом разделе «Состояние команды» отображаются индикаторы успеха, как и в единственной строке следующего раздела «Цели и результаты», в котором перечислены отдельные экземпляры из предыдущего. Внизу также есть два неразвернутых раздела: «Описание команды» и «Параметры команды».
Шаг 4: Мониторинг нашего прогресса обновления.

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

На этом этапе у нас должен быть запущен сеанс SSH.

Скриншот AWS с идентификатором сеанса и идентификатором экземпляра над терминалом. Подсказка "sh-4.2$" и команды "whoami" и "pwd" были введены с выводами "ssm-user" и "/usr/bin" соответственно.
Сеанс SSH с использованием агента SSM через диспетчер сеансов AWS Systems Manager.

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

Скриншот AWS с навигационными цепочками «CloudWatch», «Журналы CloudWatch», «Группы журналов», «ssm-session-demo» и идентификатором сеанса предыдущего шага. Единственный раздел — это поле поиска «Журнал событий» со строками, каждая из которых имеет отметку времени и сообщение в формате JSON. Один из них расширен, чтобы показать красиво напечатанный JSON и белую кнопку справа с надписью «Копировать».
События журнала SSH записываются в журналы CloudWatch.

Теперь у нас есть установка с включенным шифрованием в состоянии покоя, которая записывает каждую команду, запущенную на нашем компьютере с Linux.

На самом деле каждая команда может быть больше, чем мы хотим: любые секреты, предоставленные или сгенерированные во время сеанса, будут записаны в CloudWatch или S3, и их сможет увидеть любой, у кого есть необходимые разрешения. Чтобы предотвратить это, мы можем использовать stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; для каждого секрета, который мы должны предоставить во время сеанса.

Отличное решение для ведения журналов SSM/SSH AWS с небольшими оговорками

Диспетчер сеансов — это полезный инструмент для получения удаленного доступа к нашим виртуальным машинам в AWS без необходимости открывать порт 22. Фактически, мы не можем генерировать журналы SSH таким образом, если мы используем переадресацию портов или прямое соединение SSH, поскольку диспетчер сеансов примечания к документации.

Тем не менее, сочетание Session Manager с ведением журнала сеансов является надежным решением для контроля и мониторинга активности внутри виртуальных машин. Кроме того, с нас не взимается плата за использование службы Session Manager. Мы платим только за инстанс EC2 и журналы CloudWatch или корзину S3 для хранения журналов.

Для читателей, предпочитающих видеоуроки, я более подробно описал очень похожую процедуру на YouTube.

Дальнейшее чтение в блоге Toptal Engineering:

  • Практический пример: почему я использую облачную инфраструктуру AWS для своих продуктов