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

Какие меры можно / нужно предпринять, чтобы убедиться, что безопасность моего SSH-сервера абсолютно непроницаема?

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

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

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. Используя этот метод, я не забочусь о грубой атаке, потому что даже если он угадает мой пароль, он будет отклонен. Грубое принуждение пары открытый / закрытый ключ невозможно с современной технологией.

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

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

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

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

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

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

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

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

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

Включите двухфакторную аутентификацию с помощью 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 .

Сделайте так, чтобы клиентские IP-адреса блока sshd, которые не предоставили правильную информацию для входа в систему " DenyHØsts ", могут выполнять эту работу довольно эффективно. Я установил это на все свои Linux-боксы, которые каким-то образом доступны снаружи.

Это гарантирует, что силовые атаки на SSHD не будут эффективными, но помните (!), Что вы можете заблокировать себя, если забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.

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

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

$ sudo ufw limit OpenSSH 

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

$ sudo aptitude install ufw 

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

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

1. Установите Tor и настройте сам сервер SSH.
2. Убедитесь, что sshd только слушает localhost.
3. Open /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 на другой стороне открывает свой порт только на локальном хосте. Так что никто не может подключить его через «обычный интернет».

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

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

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

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

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

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

В последнее время я написал 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-адресов.