Загрузка
Защита Linux инфраструктуры
Учетные записи администраторов Linux являются лакомой целью для атакующих. Скомпрометировав такие УЗ, у атакующих появляется доступ к наиболее критичным компонентам инфраструктуры, таким как системам виртуализации, резервного копирования, СУБД, АБС, процессингу и т.д
Распространенные угрозы и проблемы требующие внимания, при организации доступа через SSH в Linux инфраструктуре
Логин и пароль легко перехватывается кейлоггером
Закрытый ключ в виде файла легко похитить при компрометации устройства, используемого администратором. На уровне сервера нет возможности проверить, защитил ли администратор свой ключ с помощью passphrase, при этом злоумышленник может легко похитить passphrase в момент ввода с помощью кейлоггера
В случае компрометации закрытого ключа, необходимо в кратчайшие сроки обеспечить генерацию нового закрытого ключа и распространение соответствующего открытого ключа на всех элементах инфраструктуры.
При хранении открытых ключей пользователей во внешней системе, например в LDAP, существует риск потери возможности аутентификации при недоступности внешнего хранилища. Кроме того, необходимо защитить внешнее хранилище от возможности добавления открытого ключа злоумышленника.
PAM-решения становятся в разрыв между SSH-клиентом и сервером, а значит обеспечение отказоустойчивости, включая поддержку 24х7, таких решений выходит на первый план. Также необходимо учитывать, что некоторые PAM решения, работающие через браузер, некорректно пробрасывают специфичные сочетания клавиш и нарушают форматирование при вставке многострочного текста из буфера обмена, что может повлиять на продуктивность работы администраторов. Возможность записи действий администраторов, которые предоставляют PAM решения, возможно решить альтернативными более дешевыми средствами, устанавливаемыми на jump хосты. Все эти вопросы необходимо оценивать при принятии решения о внедрении PAM решения для защиты SSH-доступа.
Подход к защите SSH-ключей
Существенно снизить риск кражи аутентификационной информации при SSH-доступе возможно за счет хранения закрытых ключей в не извлекаемой форме на аппаратных токенах или виртуальных смарт-картах, использующих TPM. При таком подходе закрытый ключ генерируется в защищенной области токена или TPM, которые выполняют все необходимые криптографические функции самостоятельно, возвращая результат SSH-клиенту при установке подключения, при этом сам закрытый ключ не покидает устройства. Токены представляют операционной системе интерфейс, позволяющий работать с ними как со смарт-картами, которые штатно пробрасываются через RDP подключения, что позволяет легко их использовать с выделенных jump хостов.
SCAT представляет собой центр сертификации SSH-PKI, который выпускает SSH-сертификаты после выполнения ряда проверок, которые позволяют гарантировать, что закрытый ключ хранится в неизвлекаемой форме. SSH-сертификаты – это стандартный способ аутентификации в Linux, не требующий установки дополнительного ПО и драйверов в серверной инфраструктуре. Для активации возможности аутентификации с использованием SSH-сертификатов на сервера необходимо обеспечить доставку открытого ключа центра сертификации (параметр TrustedUserCAKeys в sshd_config) и списка отозванных ключей (параметр RevokedKeys в sshd_config). Необходимые скрипты синхронизации и API уже реализованы в составе SCAT.
Поддерживаемые аппаратные носители SSH-ключей
Схема работы при использовании Yubikey
При использовании Yubikey, пользователь создает аттестационный сертификат, генерируемый токеном. Аттестационный сертификат Yubikey представляет собой открытый ключ, соответствующий закрытому, подписанный промежуточным центром сертификации (слот F9), зашитым при производстве токена производителем, с дополнительным набором атрибутов, таких как установленные требования к наличию PIN и необходимостью касания устройства при использовании. SCAT проверяет валидность аттестационного сертификата, а также PIN и Touch политики и в случае прохождения проверок генерирует SSH сертификат, извлекая открытый ключ из аттестационного сертификата.
Смарт-карты
При использовании других смарт-карт в том числе виртуальных необходимо использовать внешний X.509 центр сертификации, который обеспечивает выпуск X.509 сертификатов только при условии хранения закрытого ключа на смарт-карте. SCAT проверяет валидность X.509 сертификата, а также ряд его атрибутов, таких как издатель, шаблон, EKU и в случае прохождения проверок генерирует SSH-сертификат, извлекая открытый ключ из X.509 сертификата пользователя.
Генерация закрытого ключа
Настройки Linux
Использование SSH-сертификатов
Основные возможности SCAT
- Двухфакторная аутентификация пользователей при входе или интеграция с внешним OIDC провайдером
- Защита закрытого ключа центра сертификации с помощью парольной фразы, хранимой в шифрованном виде только в оперативной памяти
- Возможность создания нескольких центров сертификации, например, для разделения продуктивных и тестовых сред
- Ролевая модель на базе LDAP групп или локальных списков пользователей
- Режимы выпуска сертификата: автоматический, только после одобрения
- Определение допустимых алгоритмов ssh-ключей
- Определение ограничений для генерируемых SSH-сертификатов: максимальный срок действия, допустимые IP адреса и сети, выполняемые команды, различные возможности форвардинга (agent, X11, port) и т.д.
- Определение обязательных и опциональных principal-ов, включаемых в сертификат
- Определение политик аттестации для ключей Yubikey и X.509 сертификатов смарт-карт
- Установка в качестве идентификатора сертификата значение, содержащее автора, идентификатора запроса, что облегчает расследование при использовании не персонифицированных учетных записей
- Журналирование действий пользователей, передача событий в SIEM в CEF-формате