Обеспечьте безопасность вашего развертывания SSH с помощью двухфакторной аутентификации WiKID

SSH предлагает высокозащищенный канал для удаленного администрирования серверов. Однако, если вы столкнетесь с аудитом по нормативным или бизнес-требованиям, таким как Visa/Mastercard PCI, вам нужно быть в курсе некоторых потенциальных недостатков, связанных с аутентификацией, которые могут вызвать головную боль при аудите. Например:

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

В этом документе мы продемонстрируем, как объединить двухфакторную аутентификацию от WiKID с сервером шлюза SSH с размещенными частными ключами, чтобы создать высокозащищенное, подлежащее аудиту и простое в использовании решение для удаленного доступа. Система сильной аутентификации WiKID является коммерческим/открытым решением для двухфакторной аутентификации. Сначала мы настроим домен на сервере WiKID, затем добавим серверы в качестве сетевых клиентов на сервер WiKID, и, наконец, настроим шлюз и целевые серверы - в нашем случае, серверы Fedora Core 6.

Добавление домена на сервер WiKID

Создать домен

Создать сетевого клиента

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

Создать сетевого клиента

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

Создать сетевого клиента 2

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

Настройка SSH-шлюза

Теперь мы настроим центральный SSH-шлюз. Этот Linux-бокс является шлюзом/прокси для всех производственных серверов в ферме. Он должен быть надежно защищен, без лишнего программного обеспечения или служб, работающих на нем. Он должен иметь внешний интерфейс для входящих соединений и внутренний интерфейс для внутренних соединений. Сначала мы настроим шлюз, чтобы использовать WiKID для сильной аутентификации пользователей SSH. Отредактируйте ваш файл /etc/pam.d/sshd следующим образом:

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

Добавьте ваш сервер WiKID в файл /etc/raddb/server, используя внутренний IP-адрес сервера WiKID и общий секрет, который вы ввели на странице создания сетевого клиента:

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

Давайте добавим немного безопасности в конфигурацию SSH здесь тоже. Откройте ваш /etc/ssh/sshd_config (не файл ssh_config рядом). Добавьте эти параметры конфигурации:

#Protocol 2,1   
#Проверьте, что разрешен только протокол 2:   
Protocol 2   
#Запретить вход root:   
PermitRootLogin no   
#Запретить учетные записи без паролей:   
PermitEmptyPasswords no

Если вы хотите изменить порт, вы можете. Это не остановит злоумышленника, но может сократить количество событий в журналах, вызванных скриптовыми хакерами. Этот шлюз теперь настроен на использование одноразовых паролей WiKID для аутентификации SSH. Все пользователи должны быть зарегистрированы на сервере WiKID, и никто не может войти как root. Прежде чем покинуть этот бокс, мы сделаем что-то немного другое - мы заставим пользователей создать свои RSA-ключи на шлюзе. Как только каждый пользователь войдет в систему с помощью WiKID, пусть они создадут свои ключи:

ssh-keygen -t rsa

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

Настройка целевых серверов

Очевидно, мы настраиваем эти серверы так, чтобы они принимали входящие SSH-запросы только от шлюза. Мы делаем это, ограничивая доступ на порту 22 до наших внутренних адресов. Отредактируйте /etc/sysconfig/iptables и добавьте или измените строку для SSH на порту 22:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

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

Заключение

Удаленный SSH теперь чрезвычайно безопасен. Ни один пользователь не может получить доступ к ферме серверов, не получив сначала одноразовый код доступа от сервера WiKID. Два фактора аутентификации - это обладание токеном WiKID (и его криптографическим ключом) и знание PIN-кода. Поскольку PIN-код проверяется на сервере WiKID, очень легко отключить пользователя. Все записывается, и любой аудитор должен быть очень доволен.

Кроме того, вы можете потребовать одноразовый код доступа WiKID для доступа root на внутренних машинах. Просто создайте новый домен для su и отредактируйте /etc/pam.d/su соответствующим образом. Это также позволит вам разбить серверы на разные группы для управления. Просто создайте, например, если у вас есть набор серверов для HR, к которым только определенные администраторы имеют доступ root, их можно настроить для конкретного домена WiKID - что позволит осуществлять детальный контроль доступа и сильную аутентификацию. Получите больше информации о двухфакторной аутентификации на сайте WiKID.