Защищать сервер Ubuntu OpenSSH от атак грубой силы, но без брандмауэра или пары ключей SSH?

Я использую Ubuntu 16.04 и стараюсь ужесточить свою аутентификацию SSH особым образом.

Текущая ситуация:

У меня есть машина с минимальным сервером Ubuntu, который я использую в основном для передачи файлов через локальный сервер OpenSSH. Теперь у меня нет брандмауэра на этой машине по нескольким причинам, и я также избегаю использования пары ключей, поэтому я использую только пароль. Один из единственных способов защиты от атак методом грубой силы, который я больше всего желаю на данный момент, - это использование механизма, который блокирует пользователя на X часов после попытки соединения Y.

Желаемая ситуация:

Я хотел бы иметь автономный механизм (то есть, не являющийся частью брандмауэра), который блокирует пользователя на X часов, после того, как Y количество соединений пытается защитить от атак методом перебора.

Мой вопрос:

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

3 ответа

Решение

Вы можете сделать это с Fail2ban:

sudo apt-get install fail2ban

Затем:

sudo vim /etc/fail2ban/jail.conf

редактировать bantime установить желаемое время бана

редактировать maxretry установить максимальное количество неудачных попыток

как уже упоминалось в других комментариях, fail2ban требует iptables.


Отдельный вариант - стук порта:

Это требует только iptables, практически 0 памяти и эффективно скрывает ваш сервис от сканирования портов

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

быстрый поиск в Google показывает это: https://www.digitalocean.com/community/tutorials/how-to-configure-port-knocking-using-only-iptables-on-an-ubuntu-vps

Вы требуете iptables, хотя.

PS: я знаю, что безопасность через неизвестность вовсе не является безопасностью, но вместе с другими практиками она может помочь сделать вас более сложной целью.

Этот ответ намеревается дать возможный способ удовлетворения основного вопроса: защитить сервер Ubuntu OpenSSH от атак грубой силы, но без пары межсетевого экрана или ключа SSH?

На самом деле я предпочитаю использовать пару межсетевых экранов и SSH-ключей и нашел ответ, предоставленный Дагом Смитисом, действительно полезным.

Защитите SSH с помощью двухфакторной аутентификации

Двухфакторная аутентификация (2FA) - это тип многофакторной аутентификации. В этом примере 2FA подтверждает заявленную личность пользователя, используя комбинацию этих двух разных компонентов:

  • Основанный на времени, шестизначный код токена - код аутентификации. По умолчанию эти токены действуют в течение 30 секунд, плюс дополнительно добавляются 60 секунд, чтобы компенсировать возможный перекос времени.

  • Пароль пользователя, который сам по себе должен быть достаточно безопасным.

На самом деле, когда вы установили PermitRootLogin no и имена пользователей выбраны удачно, для меня этот метод можно назвать 3FA.

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

Давай начнем:

1. Установите зависимости

sudo apt-get install libpam-google-authenticator

2. Отредактируйте файлы конфигурации

  • редактировать /etc/pam.d/sshd и добавьте эту директиву:

    # Google Authenticator
    auth required pam_google_authenticator.so
    

    Добавьте его в начало файла. Таким образом, система сначала запросит код аутентификации, а только затем запросит пароль. Добавьте его в конец файла - система спросит первый пароль.

  • редактировать /etc/ssh/sshd_config и измените или добавьте эти директивы:

    ChallengeResponseAuthentication yes
    UsePAM yes
    PasswordAuthentication no           # You can leave this 'yes' it doesn't matter.
    

3. Активируйте двухфакторную аутентификацию для пользователя

Переключитесь на пользователя, который должен использовать двухфакторную аутентификацию и введите в терминале:

$ google-authenticator Enter

Вы хотите, чтобы токены аутентификации основывались на времени (да / нет) y Введите
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@host%3Fsecret%3DE3CY3TNSNBXXXXXX


Ваш новый секретный ключ: E3CY3TNSNBXXXXXX
Ваш проверочный код 229999
Ваши аварийные скретч-коды:
  19999711
  ...

Вы хотите, чтобы я обновил ваш файл "/home/user/.google_authenticator" (да / нет) y Введите

Вы хотите запретить многократное использование одного и того же токена аутентификации? Это ограничивает вас одним входом примерно каждые 30 секунд, но увеличивает ваши шансы заметить или даже предотвратить атаки типа "человек посередине". 
(y / n) y Enter

По умолчанию токены работают в течение 30 секунд, и для компенсации возможного перекоса времени между клиентом и сервером мы разрешаем дополнительный токен до и после текущего времени. Если у вас возникли проблемы с плохой синхронизацией времени, вы можете увеличить размер окна по умолчанию от 1:30 минут до 4 минут. Вы хотите сделать это 
(y / n) y Enter

Если компьютер, на который вы входите, не защищен от попыток входа в систему методом подбора, вы можете включить ограничение скорости для модуля аутентификации. По умолчанию это ограничивает злоумышленников не более 3 попыток входа в систему каждые 30 секунд. Вы хотите включить ограничение скорости 
(y / n) y Enter

Этот диалог создаст файл аутентификации с именем .google_authenticator размещены в домашнем каталоге пользователя. Этот файл может также использоваться для учетных записей других пользователей, если вы хотите, чтобы все они использовали одинаковые токены. Кроме того, этот файл можно настроить, а также использовать для 2FA в Apache2, но это уже другая история.

4. Генерация кодов аутентификации

Секретный ключ - E3CY3TNSNBXXXXXX - сгенерированный на предыдущем этапе используется для генерации кодов аутентификации в некотором приложении как:

5. Пример использования

В этом примере используется расширение Authenticator для Chromium/Chrome:

6. Дальнейшее чтение


РЕДАКТИРОВАТЬ:

В некоторых случаях может быть разница между часами Google и часами сервера. Вот несколько советов по этому вопросу:

К сожалению: если это VPS, возможно, у вас нет прав для этого... Если вы используете VPS, свяжитесь с вашим провайдером, чтобы решить эту проблему для вас.

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

Вам не нужно ничего устанавливать для такой защиты - просто добавьте соответствующие правила в вашу систему iptables.

1. Обязательное правило:

В начале вашего набора правил разрешите любому связанному трафику возвращаться на сервер:

sudo iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

2. Правила обнаружения и блокировки:

Установить динамический список Badguy. Обнаружение и удаление плохих IP-адресов, которые выполняют парольные атаки на SSH. Как только они попадают в список BADGUY, система отбрасывает все их пакеты:

sudo iptables -A INPUT -i eth0 -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
sudo iptables -A INPUT -i eth0 -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
sudo iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --set --name BADGUY_SSH -j ACCEPT
  • В приведенном выше коде 90000 секунд (25 часов) - это время блока.

  • Любая попытка заблокированного IP-адреса, даже не связанная с SSH (в зависимости от других правил, которые вы можете иметь или не иметь, и порядка), сбрасывает таймер времени блокировки.

3. Обнаружение твердения:

Ограничьте количество неверных паролей на соединение до 2. По умолчанию установлено значение 6.

Как sudo редактировать /etc/ssh/sshd_configи там поставили:

    MaxAuthTries 2
Другие вопросы по тегам