Как укрепить сервер SSH?

Я бы предложил:

• Использовать fail2ban для предотвращения попыток входа методом перебора.

• Отключение входа от имени root по SSH. Это означает, что злоумышленник должен будет вычислить как имя пользователя, так и пароль, что усложнит атаку.

  Добавьте PermitRootLogin no к вашему /etc/ssh/sshd_config.

• Ограничение пользователей, которые могут использовать SSH на сервере. Либо по группам, либо просто по конкретным пользователям.

  Добавьте AllowGroups group1 group2 или AllowUsers user1 user2 для ограничения того, кто может использовать SSH на сервере.

Есть одна простая вещь: установите ufw ("несложный брандмауэр") и используйте его для ограничения входящих соединений.

В командной строке наберите:

$ sudo ufw limit OpenSSH 

Если ufw не установлен, сделайте это и повторите попытку:

$ sudo aptitude install ufw 

Многие злоумышленники будут пытаться использовать ваш SSH-сервер для перебора паролей. Это позволит использовать только 6 соединений каждые 30 секунд с одного и того же IP-адреса.

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

Обычно, если вы живете в США, у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.

Скрипт можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/

Вы также можете добавить к нему команды iptables (я сделал для своих капель), чтобы автоматически отбрасывает весь трафик с этих IP-адресов.

Для большого количества пользователей / сертификатов рассмотрите возможность интеграции LDAP. Крупные организации используют LDAP в качестве репозитория для учетных данных пользователей и сертификатов, хранящихся на значках или брелках, независимо от того, используются ли сертификаты для аутентификации или подписи электронных писем. Примеры включают openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

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

Вот ссылка на интеграцию с CentOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to -fetch-public.html

Возможно, вы захотите проверить приложение FreeOTP в RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ; -)

Если вы хотите использовать другие аппаратные токены, такие как Yubikey, eToken PASS или NG, или если у вас много пользователей или много серверов, вы можете использовать бэкэнд двухфакторной аутентификации с открытым исходным кодом.

В последнее время я написал Howto об этом .

Недавно я написал небольшой учебник по этому поводу. По сути, вам нужно использовать PKI, и в моем руководстве также показано, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы не используете ни одну из этих вещей, есть некоторые лакомые кусочки о защите сервера путем удаления слабых наборов шифров и других основ. https://joscor.com/blog/harpting-openssh-server-ubuntu-14-04/

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

1. Установите Tor и настройте сам SSH-сервер.
2. Убедитесь, что sshd слушает только на localhost.
3. Откройте /etc/tor/torrc. Установите HiddenServiceDir /var/lib/tor/ssh и HiddenServicePort 22 127.0.0.1:22.
4. Посмотрите на var/lib/tor/ssh/hostname. Есть имя типа d6frsudqtx123vxf.onion. Это адрес скрытого сервиса.

5. Откройте $HOME/.ssh/config и добавьте несколько строк:

   Host myhost
   Имя хоста d6frsudqtx123vxf.onion
   ProxyCommand сокат STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
   

Кроме того, мне нужен Тор на моем местном хозяине. Если он установлен, я могу ввести ssh myhost и SSH откроет соединение через Tor. Сервер SSH на другой стороне открывает свой порт только на локальном хосте. Таким образом, никто не может подключить его через "обычный интернет".

Другие ответы обеспечивают безопасность, но есть одна вещь, которая сделает ваши журналы тише, и сделает менее вероятным, что вы будете заблокированы от своей учетной записи:

Переместите сервер с 22 порта на другой. Или на вашем шлюзе, или на сервере.

Это не увеличивает безопасность, но означает, что все случайные сканеры Интернета не будут загромождать ваши лог-файлы.

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

1. Сгенерируйте SSH-ключ, защищенный паролем, для каждого компьютера, которому необходим доступ к серверу:

   ssh-keygen

2. Разрешите SSH-доступ по SSH-ключу с разрешенных компьютеров:

   Скопируйте содержимое ~/.ssh/id_rsa.pub с каждого компьютера в отдельные строки ~/.ssh/authorized_keys на сервере или запустите ssh-copy-id [IP-адрес сервера] на каждом компьютере, к которому вы предоставляете доступ (вам нужно будет ввести пароль сервера в строке запроса).

3. Отключите пароль SSH доступа:

   Откройте /etc/ssh/sshd_config, найдите строку с надписью #PasswordAuthentication yes, и измените ее на PasswordAuthentication no. Перезапустите демона сервера SSH, чтобы применить изменение (sudo service ssh restart).

Теперь, единственный возможный способ попасть в SSH на сервере - это использовать ключ, который соответствует строке в ~/.ssh/authorized_keys. Используя этот метод, I не заботится о атаках грубой силы, так как даже если они угадают мой пароль, он будет отклонен. С сегодняшней технологией перебрасывание пары открытых/закрытых ключей невозможно.

Включить двухфакторную аутентификацию с помощью HOTP или TOTP . Это доступно с 13.10 и далее.

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

Резюме :

1. sudo apt-get install libpam-google-Authenticator

2. Попросите каждого пользователя запустить команду google-authentication , которая генерирует ~ / .google-Authenticator и помогает им настроить их двухфакторные устройства (например, приложение Google Authenticator для Android).

3. Отредактируйте / etc / ssh / sshd_config и установите:

    ChallengeResponseAuthentication yes
   Пароль Аутентификация нет
   Открытый ключ AuthenticationMethods, интерактивная клавиатура
    

4. Запустите sudo service ssh reload , чтобы сохранить изменения в / etc / ssh / sshd_config .

5. Отредактируйте /etc/pam.d/sshd и замените строку:

    @include common-auth
    

   с:

    требуется авторизация pam_google_authenticator.so
    

Более подробную информацию о различных параметрах конфигурации можно найти в моем прошлогоднем сообщении в блоге: Лучшая двухфакторная аутентификация ssh в Ubuntu .

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

См. Там статью: Обеспечение безопасности доступа SSH .

Мой подход к усилению защиты SSH ... сложен. Следующие пункты относятся к тому, как я это делаю, от крайних границ моей сети (сетей) до самих серверов.

1. Фильтрация трафика на уровне границ через IDS / IPS с помощью известных сканеров сервисов и сигнатур в черный список. Я добиваюсь этого с помощью Snort через свой пограничный брандмауэр (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с моими VPS.

2. Межсетевой экран / Сетевая фильтрация порта (ов) SSH. Я явно разрешаю доступ к моим SSH-серверам только определенным системам. Это делается либо через брандмауэр pfSense на границе моей сети, либо через брандмауэры на каждом явно настраиваемом сервере. Однако бывают случаи, когда я не могу этого сделать (что почти никогда не бывает, за исключением частных тестовых сред или лабораторий тестирования безопасности, где брандмауэры не помогают тестировать вещи).

3. В сочетании с моим pfSense, или пограничный межсетевой экран, подключенный к внутренней сети и отделяющий его от Интернета и систем, Доступ к серверам только через VPN . Мне нужен VPN в моих сетях, чтобы добраться до серверов, потому что нет портов с выходом в Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с № 2 я могу сделать один VPS «шлюзом», подключившись к этому серверу через VPN, а затем разрешить его IP-адреса другим ящикам. Таким образом, я точно знаю, что может или не может использовать SSH - мой единственный ящик - это VPN. (Или, в моей домашней сети за pfSense, мое VPN-соединение, и я единственный, у кого есть доступ к VPN).

4. Если №3 не выполним, fail2ban, настроен на блокировку после 4 неудачных попыток и блокировку IP-адреса на час или более - это достойная защита от людей, постоянно атакующих с помощью брутфорса - просто заблокируйте их на брандмауэре автоматически с помощью fail2ban, и м-м. Однако настройка fail2ban - это проблема ...

5. Обфускация портов путем изменения порта SSH. Однако НЕ стоит обходиться без каких-либо дополнительных мер безопасности - мантра «Безопасность через неизвестность» уже была опровергнута и оспаривается во многих случаях. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще ОЧЕНЬ плохая вещь, которую можно делать самостоятельно.

6. ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация через решения для двухфакторной аутентификации Duo Security . На каждом из моих SSH-серверов настроен Duo, так что для того, чтобы даже войти, появляются запросы 2FA, и я должен подтверждать каждый доступ. (Это очень полезная функция, потому что даже если кто-то узнает мою кодовую фразу или взломает ее, они не смогут пройти через плагины Duo PAM). Это одна из самых больших защит на моих SSH-серверах от несанкционированного доступа - каждый вход в систему ДОЛЖЕН быть привязан к настроенному пользователю в Duo, и, поскольку у меня есть ограничительный набор, новые пользователи не могут быть зарегистрированы в системе. два цента на защиту SSH. Или, по крайней мере, мои мысли о подходе.