Защита Ubuntu: двухфакторная аутентификация с Google Authenticator

Почему это важно

Война между злоумышленниками и специалистами по информационной безопасности идёт постоянно. Уязвимость одного только пароля — частая причина взломов. Двухфакторная аутентификация снижает риск, потому что злоумышленнику понадобится и пароль, и доступ к дополнительному фактору (в нашем случае — мобильному устройству с приложением).

Ключевой принцип: пароли — это что-то, что вы знаете; код в приложении — это что-то, что вы имеете. Даже при компрометации пароля злоумышленник не получит доступа без второго фактора.

Важно: смс-сообщения менее надёжны, чем одноразовые коды в приложении, из‑за атак на замену SIM. Google Authenticator реализует протокол TOTP и генерирует коды локально.

Что понадобится

• Ubuntu 16.04 (рабочая станция или сервер). Подойдёт и более новые версии Ubuntu; в разделе совместимости — подробности.
• Мобильное устройство с Android или iOS.
• Приложение Google Authenticator (Google Play или App Store).

Избегайте привязки критичных учётных записей без резервной стратегии для восстановления доступа.

Быстрый обзор шагов

1. Установить пакет libpam-google-authenticator на Ubuntu.
2. Изменить PAM-конфигурацию для включения проверки Google Authenticator при входе и sudo.
3. Запустить google-authenticator для каждого пользователя и привязать аккаунт через QR-код или ключ.
4. Настроить мобильное приложение: сканировать QR или ввести ключ вручную.
5. Протестировать вход и sudo; проверить сценарии восстановления и отката.

Установка Google Authenticator на мобильном устройстве

Откройте Google Play или App Store и установите «Google Authenticator», опубликованный Google Inc. После установки приложение готово к добавлению аккаунтов.

Image credit: designer491 via Shutterstock

Установка на Ubuntu

Откройте терминал на целевой машине. Выполните команду установки пакета PAM для Google Authenticator:

sudo apt-get update
sudo apt-get install libpam-google-authenticator

При запросе введите пароль пользователя, подтвердите установку нажатием Y, если требуется.

Важно: для серверов без GUI убедитесь, что у вас есть рабочая консоль или удалённый терминал с правами root для операций восстановления.

Настройка PAM

Мы будем править общий файл аутентификации PAM. Сделайте резервную копию перед изменениями:

sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak

Откройте файл в редакторе:

sudo nano /etc/pam.d/common-auth

Найдите строку, похожую на:

auth [success=1 default=ignore] pam_unix.so nullok_secure

И добавьте непосредственно над ней строку:

auth required pam_google_authenticator.so

Сохраните изменения (Ctrl+X, затем Y и Enter в nano).

Примечание: порядок строк в PAM важен. Если вы ошибётесь, можно потерять возможность войти. Если доступ потерян, используйте режим восстановления (recovery mode) или загрузку с Live‑USB, чтобы восстановить /etc/pam.d/common-auth из резервной копии.

Привязка пользователя к Google Authenticator

Каждый пользователь должен запустить команду google-authenticator под своей учётной записью. Пример для пользователя makeuseof:

# под обычным пользователем (не root)
google-authenticator

Команда выдаст:

• QR-код (для сканирования приложением)
• Разовый проверочный код
• Секретный ключ (base32)
• 5 запасных одноразовых кодов (scratch codes)

Следуйте подсказкам. По умолчанию можно отвечать Y на большинство вопросов. Рекомендуем сохранять scratch-коды в защищённом месте (например, зашифрованный менеджер паролей или физическая печать в надёжном хранилище).

Описание: терминал с QR-кодом, секретным ключом и запасными кодами для привязки аккаунта.

Ключевые понятия: TOTP — протокол временных одноразовых паролей, обычно с 30‑секундным окном валидности; scratch-коды — одноразовые резервные коды на случай потери устройства.

Настройка мобильного приложения

Откройте Google Authenticator. Нажмите «Начать» или плюс внизу, затем «Сканировать QR-код» или «Введите ключ вручную». Если камера устройства плохо работает, выберите ввод ключа и укажите произвольное имя аккаунта (например, makeuseof), затем вставьте секретный ключ из терминала.

Если вы сканировали QR, приложение автоматически добавит аккаунт и начнёт генерировать шестизначные коды.

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

Проверка работы и переключение пользователей

Для проверки можно открыть новую сессию входа или применить sudo. Пример для входа под другим пользователем:

sudo su slaghoople
# в сессии slaghoople
google-authenticator

После настройки у пользователя при входе и при выполнении sudo будет запрашиваться шестизначный код из приложения.

Протестируйте:

1. Выйдите из текущей сессии и снова войдите (или подключитесь по SSH).
2. При запросе введите пароль и затем код из Google Authenticator.
3. Выполните команду sudo — система должна потребовать код.

Типичные проблемы и способы устранения

• Проблема: После изменения /etc/pam.d/common-auth вы потеряли доступ.
  • Решение: загрузитесь в recovery mode или Live‑USB, восстановите /etc/pam.d/common-auth из /etc/pam.d/common-auth.bak и перезагрузитесь.
• Проблема: Временные коды не принимаются.
  • Проверка: синхронизируйте время на сервере и на мобильном устройстве. TOTP чувствителен к отклонению времени; на серверах рекомендуется настроить NTP.
• Проблема: Пользователь потерял телефон.
  • Решение: используйте заранее сохранённые scratch-коды; если они недоступны, выполните восстановление учётной записи через консоль администратора или временно отключите требование PAM для этого пользователя, затем выполните повторную привязку.
• Проблема: Множественные учётные записи на одном устройстве мешают различать коды.
  • Решение: давайте понятные имена при добавлении аккаунтов (например, server1-username).

Откат и аварийный план

Перед внесением изменений:

1. Создайте резервные копии файлов PAM и других конфигураций.
2. Убедитесь, что есть как минимум один способ доступа с привилегиями root (например, физический доступ или консоль панели управления хостинга).

Если потребуется откат:

# из recovery mode или с Live-CD
sudo cp /etc/pam.d/common-auth.bak /etc/pam.d/common-auth
reboot

Если у пользователя нет scratch-кодов и он потерял телефон, администратор может временно выключить требование pam_google_authenticator, войти и сгенерировать новый ключ для пользователя.

Безопасность и жёсткая защита

• Не храните секретные ключи в незашифрованных файлах или в облачных заметках без шифрования.
• Используйте NTP для точной синхронизации времени на сервере.
• Рассмотрите возможность использования аппаратных 2FA-ключей (U2F/FIDO2) для повышенной безопасности.
• Ограничьте логины по SSH по IP-адресам или используйте VPN для доступа к серверам.

Когда 2FA может подвести

• Если злоумышленник имеет доступ и к паролю, и к мобильному устройству — защита сработает слабо.
• Социальная инженерия и фишинг могут заставить пользователя выдать код.
• Потеря мобильного устройства без запасных кодов приведёт к потере доступа.

Контрмеры: вычислять аномальную активность, применять MFA с аппаратными ключами, хранить резервные коды в защищённом хранилище.

Альтернативы и расширения

• Аппаратные ключи (YubiKey, FIDO2) — более стойкие к фишингу и похищению SIM.
• Authy — приложение, которое поддерживает облачное резервное копирование зашифрованных ключей (удобно, но требует доверия к провайдеру).
• Включение 2FA на самом уровне приложений и облачных сервисов (GitHub, Google, провайдеры хостинга).

Совместимость и рекомендации по версиям

• Пакет libpam-google-authenticator доступен для большинства LTS‑версий Ubuntu. На более новых версиях команды те же, но пакеты и зависимости могут отличаться.
• Для Ubuntu 18.04 и 20.04 инструкция применима, но всегда проверяйте наличие пакета в репозитории: sudo apt-get update && apt-cache policy libpam-google-authenticator.
• На облачных хостингах проверьте, не блокирует ли панель управления изменения PAM.

Конфиденциальность и соответствие требованиям (GDPR)

• Секреты Google Authenticator хранятся локально в файле ~/.google_authenticator для каждого пользователя. Эти данные не передаются в сторонние сервисы при нормальной работе.
• Если ваша организация обязана по GDPR обеспечивать удаление персональных данных, учитывайте, что секреты TOTP — персональные данные в контексте привязки к учётной записи; удаляйте их по запросу, но предоставьте безопасный процесс восстановления доступа.

Практические сценарии: рольовые чеклисты

Для администратора:

• Сделать резервную копию /etc/pam.d/common-auth.
• Настроить NTP.
• Установить libpam-google-authenticator.
• Протестировать привязку для тестовой учетной записи.
• Подготовить SOP для восстановления доступа.

Для пользователя:

• Запустить google-authenticator и сохранить scratch-коды в защищённом месте.
• Сканировать QR-код в мобильном приложении.
• Проверить вход и использование sudo.
• Сообщить администратору при потере устройства.

SOP: быстрый план настройки (короткая версия)

1. Резерв: cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak
2. Установка: sudo apt-get install libpam-google-authenticator
3. PAM: добавить auth required pam_google_authenticator.so в /etc/pam.d/common-auth
4. Для каждого пользователя: запустить google-authenticator и привязать приложение
5. Тестирование: проверить вход, sudo, восстановление

Критерии приёмки

• Пользователь при входе и при sudo запрашивается шестизначный код из приложения.
• Временные коды принимаются корректно при синхронизированном времени.
• Резервный сценарий отката проверен и работает (восстановление /etc/pam.d/common-auth.bak).

Тестовые случаи

• TC1: Новый пользователь запускает google-authenticator и успешно авторизуется при входе.
• TC2: Синхронизация времени нарушена — код отклоняется; после включения NTP коды проходят.
• TC3: Потерян телефон; пользователь использует scratch-code для входа и затем генерирует новый ключ.

Ментальные модели и эвристики

• «Что-то, что вы знаете» + «что-то, что вы имеете». Даже если первое скомпрометировано, второе остаётся барьером.
• Третья модель: уменьшение площади атаки — каждый дополнительный фактор экспоненциально усложняет массовый взлом.

Факты о TOTP (коротко)

• Формат: шестизначные коды по стандарту TOTP.
• Период жизни кода: обычно 30 секунд.
• Секрет хранится локально в ~/.google_authenticator и должен быть защищён.

Диаграмма принятия решения

flowchart TD
  A[Начало: нужен 2FA на Ubuntu?] --> B{Есть ли физический доступ к серверу?}
  B -- Да --> C[Настроить 2FA локально + хранить scratch-коды оффлайн]
  B -- Нет --> D{Можно ли обеспечить восстановление доступа через хостинг?}
  D -- Да --> E[Настроить 2FA и задокументировать процедуру восстановления]
  D -- Нет --> F[Рассмотреть аппаратные ключи или бесшовные MFA у провайдера]
  C --> G[Тестирование и мониторинг]
  E --> G
  F --> G
  G --> H[Готово]

Шаблон для записи секретов (пример)

• Имя сервера: server1
• Пользователь: makeuseof
• Секрет (base32): XXXXX-XXXXX-XXXXX
• Scratch-коды (5): 11111111,22222222,… (хранить зашифрованно)
• Дата настройки: 2025-xx-xx

Храните этот шаблон только в зашифрованном хранилище.

Заключение и рекомендации

Двухфакторная аутентификация с Google Authenticator — это недорогой и эффективный способ значительно повысить безопасность входа в систему и выполнение команд с повышенными привилегиями. Она не устранит все риски, но значительно уменьшит шанс успешного взлома при компрометации пароля. Для наиболее чувствительных сред комбинируйте TOTP с аппаратными ключами и ограничениями доступа по сети.

Важно: тестируйте сценарии восстановления заранее и документируйте процесс для пользователей и администраторов.

Если у вас остались вопросы по конкретным шагам или у вас особая конфигурация (LDAP, централизованная аутентификация, SSH без пароля), опишите её — я помогу адаптировать инструкцию.

Image Credit: Dave Clark Digital Photo via Shutterstock.com