Часто задаваемый вопрос, как надежно защитить свой VPS / выделенный сервер от взлома? Поэтому я решил написать инструкцию о внедрении двухфакторной аутентификации.
2FA является вторым уровнем защиты данных, благодаря которому получить доступ к учетной записи можно только после подтверждения собственной личности. Теперь, даже если злоумышленник будет знать логин и пароль, благодаря двухфакторной аутентификации он не сможет получить доступ к вашему серверу.
Наличие двухфакторной аутентификации сводит вероятность доступа злоумышленников к учетной записи практически к нулю, гарантируя сохранность данных пользователя.
Если вы до сих пор убеждены в том, что, придумывая сложный пароль, вы гарантированно защитите свой сервер от взлома, а все личные данные от кражи, вы глубоко заблуждаетесь. На сегодняшний день хакеры используют огромное количество способов для быстрого подбора даже самых сложных паролей, потому двухфакторная аутентификация является важнейшей мерой безопасности, которой не стоит пренебрегать.
Берем в руки телефон и осуществляем настройку приложения аутентификатора. Сделать это достаточно просто. Можно использовать разные программы, но я рекомендую Twilio Authy 2-Factor Authentication.
Скачать ее можно по этой ссылке: https://play.google.com/store/apps/details?id=com.authy.authy&hl=ru.
Официальный сайт программы: authy.com
Преимуществом Twilio Authy 2-Factor Authentication является возможность работать сразу на нескольких устройствах одновременно, даже на десктопе или ноутбуке. В Google Authenticator такой возможности нет. Если вы вдруг потеряете свой смартфон, вы сохраните все свои данные для доступа к аккаунтам.
Устанавливаем приложение с Google Play и запускаем его. Затем система попросит ввести код страны и номер телефона. Обязательно указывайте тот номер телефона, к которому у вас имеется доступ. Также не забудьте указать свой e-mail.
Следующий шаг – подтверждение. Выберите тот способ, который наиболее удобен для вас – получение sms-сообщения или ответ на звонок.
Пакет аутентификатора нужно будет установить в систему. Делается это следующим образом:
Для Debian 9/10:
root@alexhost:~# apt install libpam-google-authenticator - y
Для CentOS в первую очередь нужно будет подключить epel репозиторий:
root@alexhost:~# yum install epel-release
Только после этого можно будет установить пакет:
root@alexhost:~# yum install google-authenticator
На следующем этапе запускаем:
root@alexhost:~# google-authenticator
Система задаст вопрос: Do you want authentication tokens to be time-based (y/n. Отвечаем y, т.к такой вариант наиболее надёжный.
На вопрос “Do you want me to update your "/root/.google_authenticator" file? (y/n)” отвечаем y.
На вопрос “Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n)” отвечаем в зависимости от того, насколько сильно вы беспокоитесь о безопасности и готовы ради нее пожертвовать удобством.
Дело в том, что войти, используя аутентификатор, можно будет не чаще, чем раз в 30 секунд. Не слишком удобно, но однозначно безопаснее.
Дальше нас ждет еще один вопрос: “By default, a new token is generated every 30 seconds by the mobile app. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. Do you want to do so? (y/n)” отвечаем y
Очередной вопрос: “If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s”.
Вновь смотрите, что для вас важнее – удобство или безопасность. Единственного правильного ответа нет, все зависит от ваших предпочтений. Если вы ответите y, система разрешит не более 3 попыток входа в течение 30 секунд.
Следующее, что вам нужно будет сделать – это нажать на + в приложении аутентификаторе и отсканировать предложенный qr код в терминале
Затем понадобится установить защитный пароль для бекапов, который будет состоять минимум из 6 символов. Разумеется, все аккаунты, добавленные в приложение, сохраняются в облаке.
Сохраните свой аккаунт под любым удобным вам именем
Внимание! Не забудьте записать экстренные коды. В рассматриваемом нами случае, это:
Your emergency scratch codes are:
13455461
88816366
91315051
48752467
40022285
root@alexhost:~# nano /etc/pam.d/sshd
В самом конце файла необходимо будет добавить “auth required pam_google_authenticator.so”
Сохраните файл Ctrl+O, а затем нажмите Enter
Выходим из редактора, нажав одновременно клавиши Ctrl+X
Кстати, вы без проблем сможете воспользоваться другим текстовым редактором. Вам вовсе необязательно использовать nano
Следующее, что нужно сделать:
“root@alexhost:~# nano /etc/ssh/sshd_config” заменить “ChallengeResponseAuthentication no” на “ChallengeResponseAuthentication yes”
Не забудьте обязательно добавить в конце файла “AuthenticationMethods keyboard-interactive”
Нажимаем Ctrl+O и сохраняем файл, затем Enter
Выходим из редактора Ctrl+X
На одном из последних этапов нужно будет перезапустить службу ssh:
root@alexhost:~# systemctl restart sshd
Подключаемся. Система сперва запрашивает пароль, затем двухфакторный ключ
Вот и все – поздравляем, настройка успешно завершена!
Немного рекламы
1.5 GB RAM / 1 Ядро / 10GB SSD диска — 4€ /месяц или 11.88 € в год!
4GB RAM / 2 Ядро / 40GB SSD диска — 10€ /месяц или 60 € в год!
8GB RAM / 4 Ядра / 80GB SSD диска — от 16€ /месяц или 144 € в год!
ТУТ — AlexHost.com
Bonio
А почему просто не использовать авторизацию по ключу?
VolCh
Это один фактор
saipr
А почему просто не использовать двухфакторную авторизацию с токенами PKCS#11, на котором хранится личный сертификат владельца?
ivlad
Это не важно. Проблема не в одном или двух факторах. Проблема в том, что люди пароли плохие выбирают, используют их повторно в разных местах и фишингу пароли подвержены.
Второй фактор на OTP частично, но не полностью, решает эти проблемы. Аутентификация по ключам решает эти проблемы целиком.
VolCh
Ключи не пересипользуют, не шарят, в репозитории, в том числе публичные, не комитят?
ivlad
Переиспользование одного ключа в нескольких сервисах особых проблем не создаёт. Можно понять, что Вася тут — это Петя в Гитхабе, да и всё, пожалуй.
Публичный ключ не страшно комитить в репозитории, на то он и публичный. Приватный ключ секретный. Разумеется, кто-то может сдуру закомитить его в репозиторий, но чем это отличается от комита OTP секрета? Кстати, приватный ключ в отличие от OTP секрета ssh-keygen предлагает зашифровать.
VolCh
Ага, для каждого сервера организации используем один приватный ключ для админского доступа и тут он втихую утекает…
ivlad
Как я сказал, ключи на диске зашифрованные. Чтобы ключ утёк, должна быть скомпроментирована машина админа. Если скомпроментирована машина админа, то утекает много другого (например, OTP секрет, на этой машине оказавшийся).
Как выше замечено, если очень хочется, чтобы ключи не утекали даже при компроментации машины, можно их положить в PKCS#11 токен, подключаемый через USB. Можно ruToken взять, Yubikey или любой другой, с неоходимыми драйверами.
disakov
Если OTP там оказался, то это промашка или орг процесса, или халатность. Но это так, придирка, извините. Про токен отличная идея.