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

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

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

Резюме:

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

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

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

   ChallengeResponseAuthentication yes
   PasswordAuthentication no
   AuthenticationMethods publickey,keyboard-interactive
   

4. Выполните sudo service ssh reload, чтобы забрать ваши изменения в /etc/ssh/sshd_config.

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

   @include common-auth
   

   на:

   auth required pam_google_authenticator.so
   

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

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

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

   ssh-keygen

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

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

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

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

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

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

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

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

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

$ sudo ufw limit OpenSSH 

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

$ sudo aptitude install ufw 

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

Если я хочу иметь дополнительную безопасность или мне нужен доступ к 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
   HostName d6frsudqtx123vxf.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
   

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

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

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

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

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

Для большого количества пользователей / сертификатов рассмотрите возможность интеграции с 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

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

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

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

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

Мой подход к укреплению 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, и meh. Конфигурирование fail2ban - это боль, хотя ...

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

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

Мои два цента для защиты SSH. Или, по крайней мере, мои мысли о приближении.