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


128

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

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


44
Абсолютная непроницаемость требует выключения коробки.
Турбьерн Равн Андерсен

Что делать, если у вас есть Wake-on-LAN?
ребус

Проблема будет в части локальной сети ... Пакеты Wake-on-LAN не маршрутизируются, поэтому вам потребуется доступ к машине внутри локальной сети для отправки пакета WOL ...
LassePoulsen

Для аутентификации ключа вы можете ограничить шифры теми шифрами, которые вам действительно нужны.

Ответы:


108

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

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


5
-1: как правило, доступ предоставляется отдельным компьютерам, а не создавать ключ для каждого потенциального клиентского компьютера, подключающегося к серверу. Ваше последнее утверждение неверно, согласно вашему предложению, а также потому, что вы не предлагали устанавливать фразу-пароль для закрытых ключей, имеющих доступ / компрометацию к любой из клиентских систем, автоматически предоставит доступ к SSH-серверу. Рекомендуется аутентификация по ключу SSH, но закрытые ключи должны быть надлежащим образом защищены, и их следует использовать на индивидуальной основе, а не распределенным образом, как описано.
Жоау Пинту

7
«Обычно доступ предоставляется отдельным, а не компьютерам, создание ключа для каждого потенциального клиентского компьютера, подключающегося к серверу, нецелесообразно». Существует много вариантов, и я думаю, что описание безопасной передачи секретного ключа каждому клиенту выходит за рамки этого вопроса. , Я не представляю все варианты, просто простой, который, я думаю, люди могут понять. «... следует использовать на индивидуальной основе, а не распределенным образом, как описано». Это, кажется, противоречит вашему предыдущему утверждению, и я не описал ничего как распределенное.
Аса Айерс

5
«невозможно», возможно, немного переусердствовало.
Турбьерн Равн Андерсен

9
Вот почему я говорю «невозможно». Ни у кого нет компьютеров так быстро, так мало или столько времени. «Представьте себе компьютер размером с песчинку, который может проверять ключи на наличие некоторых зашифрованных данных. Также представьте, что он может проверять ключ в течение времени, которое требуется для его пересечения. Затем рассмотрим кластер этих компьютеров, так много, что если бы вы покрыли ими землю, они покрыли бы всю планету до высоты 1 м. Кластер компьютеров взломал бы 128-битный ключ в среднем за 1000 лет ».
Аса Айерс

@ ThorbjørnRavnAndersen «Невозможно» не слишком преувеличивает, если вы используете сильную клавишу. Я не могу найти цитату прямо сейчас, но при нынешней длине ключа атаки методом "грубой силы" невозможны, "пока компьютеры не состоят из чего-то иного, чем материя, и занимают что-то иное, чем пространство".
Максимилиан Лаумейстер

72

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

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

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

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

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

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


2
В AllowUsers и AllowGroups не принимает запятую , в качестве разделителя. Убедитесь, что вы не пытаетесь сделать это удаленно. Я продолжаю блокироваться из своего NAS, делая это неправильно.
бесхитростный шум

4
Всегда проверяйте правильность вашей sshdконфигурации перед тем, как перезапустить sshd, чтобы избежать блокировки самостоятельно. Смотрите этот блог для деталей - просто запустите sshd -Tпосле изменения конфигурации, прежде чем перезапустить основной sshd. Кроме того, когда вы вносите изменения в конфигурацию, на компьютере должен быть открыт сеанс SSH , и не закрывайте его, пока вы не проверили конфигурацию, как было упомянуто, и, возможно, не выполнили тестовый вход в систему SSH.
RichVel

24

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

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

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


1
Для тех, кто верит в безопасность по неизвестности ( en.wikipedia.org/wiki/Security_through_obscurity ), имеет смысл использовать другой порт. Хотя я не ..
LassePoulsen

32
Речь идет не о безопасности через неизвестность (хотя неизвестность может иметь незначительный положительный эффект). Речь идет о снижении фонового шума бесконечных попыток грубой силы. Вы не можете с пользой проверять журналы сбоев доступа, если они полны автоматических атак; fail2ban не уменьшает объем достаточно, учитывая количество атакующих и распространенность (ботнет) и ограниченные атаки. Если вы используете ssh для необычного порта, вы знаете, что атаки, которые вы видите в журналах, происходят от реального злоумышленника, интересующегося вашей коробкой. Я настоятельно рекомендую это.
bobince

Поскольку вы можете запрашивать интернет-сервисы, такие как shodan, о ssh-серверах, обращенных к сети, или использовать nmap и захват баннеров, изменение порта по умолчанию практически бессмысленно. Я бы посоветовал против этого.
Меньше Лорис

Shodan не захватывает все порты 65k, поэтому переход на высокий порт, скорее всего, удалит его из сканирования. Кроме того, если вы перейдете на случайный высокий порт, злоумышленнику, вероятно, потребуется выполнить 65K-сканирование TCP (очень шумно), чтобы найти ваш сервис, чтобы начать атаковать его. И то и другое выигрывает с точки зрения безопасности, поэтому переход на высокий порт - это, как правило, хороший план. Другая причина заключается в том, что при переходе на высокий порт вы можете лучше понять, что кто-то, кто вас атакует, нацелен на ваши системы, а не просто на общий фоновый шум в Интернете
Рори МакКьюн

23

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


21

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

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


2
Есть ли какая-нибудь опция, например, 10 неудачных попыток входа в систему до запрета IP-адреса?
Саянтанхан

20

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

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

$ sudo ufw limit OpenSSH 

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

$ sudo aptitude install ufw 

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


+1 Использование лимита может быть хорошо. Однако следует отметить, что я столкнулся с проблемами при использовании встроенного сервера sftp, так как он ограничивает соединения для этого.
Марк Дэвидсон

2
@ Марк - хорошая мысль, но разве это не похоже на плохо написанный SFTP-клиент? Зачем им продолжать подключаться к порту SSH, когда они могут просто открыть больше каналов SSH?
mpontillo

12

Если я хочу иметь дополнительную безопасность или мне нужен доступ к 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 на другой стороне открывает свой порт только на локальном хосте. Так что никто не может подключить его через «обычный интернет».


10
Безопасность продвинутой неизвестностью, но очень интересная.
Йоханнес

8

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

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


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

1
Хорошая идея. Хотя я нахожусь в период с гораздо меньшим количеством времени для участия. Мой ответ - «Вики сообщества», поэтому не стесняйтесь добавлять информацию о ссылке, если у вас есть время.
Гюйгенс

6

Мой подход к укреплению 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. Или, по крайней мере, мои мысли о приближении.


1

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

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

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


0

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


0

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


0

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

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

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

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


1
Иногда базы данных GeoIP могут быть неправильными - меня спросили, был ли я вчера в Москве ... да нет! :)
Шон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.