Вопрос Как закрепить SSH-сервер?


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

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


119


происхождения


Абсолютная непроницаемость требует выключения коробки. - Thorbjørn Ravn Andersen
Что делать, если у вас есть Wake-on-LAN? - rebus
Проблема будет в локальной части ... Пакеты Wake-on-LAN не маршрутизируются, поэтому вам нужно будет иметь доступ к машине внутри локальной сети для отправки пакета WOL ... - LassePoulsen
Для проверки подлинности ключей вы можете ограничить шифры шифрами, которые вам действительно нужны.


ответы:


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

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


100



-1: Обычно доступ предоставляется отдельным не компьютерам, создание ключа для каждого потенциального клиентского компьютера, подключенного к серверу, необоснованно. Ваше последнее утверждение неверно, в соответствии с вашим предложением и потому, что вы не предлагали устанавливать кодовую фразу для закрытых ключей, имеющих доступ / компрометацию любой из клиентских систем, автоматически предоставляли бы доступ к SSH-серверу. Рекомендуется использовать аутентификацию ключа SSH, но частные ключи должны быть надлежащим образом защищены, и их следует использовать на индивидуальной основе, а не в распределенной форме, как описано. - João Pinto
«Обычно доступ предоставляется отдельным не компьютерам, создание ключа для каждого потенциального клиентского компьютера, подключающегося к серверу, необоснованно» Существует много вариантов, и я думаю, что описание того, как безопасно передавать закрытый ключ каждому клиенту, выходит за рамки этого вопроса , Я не представляю все варианты, просто простые, которые, как я думаю, люди могут понять. «... следует использовать на индивидуальной основе, а не в распределенной форме, как описано« Это, кажется, противоречит вашему предыдущему утверждению, и я не описывал ничего как распространенное. - Asa Ayers
«невозможно», возможно, немного переусердствует. - Thorbjørn Ravn Andersen
Вот почему я говорю «невозможно». У кого-то нет компьютеров, которые бы быстро это мало, это много или много времени. «Представьте себе компьютер, размер песка, который может проверять ключи от некоторых зашифрованных данных. Также представьте, что он может протестировать ключ в количестве времени, которое требуется для перехода на свет, а затем рассмотреть кластер этих компьютеров, так много, что, если бы вы покрыли Землю ими, они покрывали бы всю планету на высоту 1 метр. Кластер компьютеров взломал бы 128-битный ключ в среднем за 1000 лет ». - Asa Ayers


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

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

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

    Добавить PermitRootLogin no на ваш /etc/ssh/sshd_config,

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

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


67



AllowUsers а также AllowGroups не принимает запятую , как разделитель. Убедитесь, что вы не пробовали это дистанционно. Я все время отключаюсь от своего NAS, делая это неправильно. - artless noise
Всегда проверяйте ваш sshd Конфигурация правильная, прежде чем перезапустить sshd, чтобы избежать блокировки себя из машины. Видеть этот блог для подробностей - просто запустите sshd -T после изменения конфигурации перед перезапуском основного sshd, Также, открыть сеанс SSH на машине, когда вы измените конфигурацию, и не закрывайте ее до тех пор, пока вы не подтвердите конфигурацию, как упомянуто, и, возможно, выполнили проверку SSH-входа. - RichVel


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

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

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


22



Для тех, кто верит в безопасность безвестности (en.wikipedia.org/wiki/Security_through_obscurity), имеет смысл использовать другой порт. Я не понимаю. - LassePoulsen
Речь идет не о безопасности через Obscurity (хотя неясность может иметь незначительный положительный эффект). Речь идет об уменьшении фонового шума бесконечных попыток грубой силы. Вы не можете с пользой провести аудит журналов сбоев доступа, если они полны автоматических атак; fail2ban не уменьшает объем, достаточный, учитывая количество нападавших и распространенность распределенных (ботнет) и дросселированных атак. С помощью ssh на необычном порту вы знать атаки, которые вы видите в журналах, происходят от реального злоумышленника, заинтересованного вашей коробкой. Я настоятельно рекомендую. - bobince
Поскольку вы можете запрашивать интернет-услуги, такие как shodan для веб-серверов ssh, или использовать nmap и захват баннеров, делает изменение порта по умолчанию довольно бессмысленным. я бы советовал против этого. - SLow Loris
Shodan не захватывает все порты 65k, поэтому переход на высокий порт скорее всего удалит его из сканирования. Также, если вы перейдете на случайный высокий порт, злоумышленнику, вероятно, потребуется выполнить 65K TCP-сканирование (очень шумно), чтобы найти ваш сервис, чтобы начать атаковать его. Оба они выигрывают с точки зрения безопасности, поэтому переход к высокому порту обычно является хорошим планом. Другое дело, что, перейдя на высокий порт, вы можете лучше понять, что кто-то, кто атакует вас, нацеливается на ваши системы, а не только на общий фоновый интернет-шум - Rоry McCune


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

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


21



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


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

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

Резюме:

  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





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

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

$ sudo ufw limit OpenSSH 

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

$ sudo aptitude install ufw 

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


19



+1 Использование лимита может быть хорошим. Однако следует указать, что я столкнулся с проблемами при использовании встроенного сервера sftp, поскольку он также ограничивает соединения для этого. - Mark Davidson
@Mark - хороший момент, но разве это не похоже на плохо написанный SFTP-клиент? Почему они должны переподключиться к порту SSH, когда они могут просто открыть больше SSH-каналов? - mpontillo


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


12



Безопасность с помощью передовой неясности, но очень интересная. - Johannes


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

См. Там статью: Сохранение доступа к SSH,


8



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


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

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

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

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

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

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

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

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


6





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

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

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


1