Повышение безопасности ssh
С чего начинается сервер?
Со входа по SSH
Secure shell — основной инструмент для управления сервером. То, с чего начинается работа системного администратора.
По умолчанию служба работает на 22 порту и подвержена множеству опасностей: брутфорс паролей ботнетом, целенаправленному подбору хакерами и даже DDoS. А утечка паролей и потеря доступа к серверу может привести к катастрофическим последствиям для бизнеса и психики.
В этой статье мы расскажем, как сделать доступ по SSH максимально закрытым и избавить себя от всевозможных рисков.
Важный момент: следует делать всё аккуратно и иметь в соседней вкладке терминала рабочую сессию, чтобы в случае возникновения проблем не выстрелить себе в колено была возможность откатить изменения.
Конфиг SSH
Первым делом правим в конфиге демона SSH:
И меняем дефолтные параметры:
Отключение авторизации по паролю — каким бы он не был надежным, всегда есть вероятность его подбора. Важно убедиться, что подключение по SSH-ключам работает, иначе подключиться к серверу без VNC или rescue вы не сможете.
Если на сервере несколько IP-адресов, то этим параметром мы указываем, какой именно IP на сервере должна слушать служба.
По умолчанию при подключении по SSH у вас есть две минуты, чтобы ввести пароль. Если не успеете, то соединение будет прервано. Ставим минуту или даже тридцать секунд.
Отключаем авторизацию суперпользователя root. Он имеет неограниченную власть над системой и именно к нему чаще всего пытаются подобрать пароль. Важно, чтобы в системе уже были созданы другие пользователи с sudo-правами, под которыми в дальнейшем будет осуществляться подключение по SSH.
Задается время (в секундах) бездействия сессии, после чего она будет прервана. Важно не ставить низкие значения, иначе кроме неудобств при работе вам это ничего не принесёт.
Количество проверок активности сессии, тесно связанный с предыдущим параметром. Если в течение заданного количества попыток (по умолчанию три) сервер не получит ответа, то соединение завершится. Так как мы выставили значение ClientAliveInterval равное десяти минутам, то этот параметр можно выключить, задав ноль.
После всех настроек перезапускаем SSH ( текущая сессия при этом не обрывается):
На выходе мы получаем нестандартный порт, который слушает определенный диапазон IP-адресов и доступ возможен только по ключу SSH или сверхнадежному паролю и не юзеру root. Как его сгенерировать и где хранить, можно прочитать в другой нашей статье.
Фаервол
Помимо изменения настроек самой службы, следует также разрешить подключение только с определенных IP-адресов с помощью Iptables и блокировать слишком частые попытки авторизоваться с неправильным паролем используя Fail2ban.
Iptables
Утилита для управления брандмауэром netfiler. Установлена по умолчанию. Пример команды:
Которая разрешает подключение по 22 порту из указанной подсети — если вы меняли порт на предыдущем шаге, то следует заменить его и здесь.
Для остальных диапазонов IP подключение можно запретить правилом:
Если вы ранее изменяли порт SSH, то соответственно необходимо поправить и правило.
Fail2ban
Ставится командами apt/yum install fail2ban в зависимости от используемой ОС.
После установки защита SSH работает сразу. Можно подправить правила в файле /etc/fail2ban/jail.conf или создать отдельный конфиг /etc/fail2ban/jail.d/ssh.conf
В секции [ssh] указываем желаемые параметры:
ignoreip — список адресов, которые не будут блокироваться при истечении неудачных попыток авторизации. Сюда следует добавить IP-адреса, к которым будете подключаться к серверу.
findtime — интервал времени, в течение которого считаются попытки подключения. Стандартное значение — 10 минут, рекомендуем ставить значение меньше, например, 5 минут.
maxretry — собственно, количество неудачных попыток авторизации перед тем, как адрес будет заблокирован. Ставим 5.
bantime — время, на которое будет блокироваться подозрительный адрес.
Пример настроек секции:
Если в течение пяти минут будет три неудачных попыток авторизации, то адрес, попавший под санкции, будет заблокирован на два часа.
Список заблокированных адресов можно будет посмотреть командой:
Таким образом, мы разрешаем подключаться только из определенной подсети, а частые неудачные попытки будут блокироваться.
Двухфакторная аутентификация
2FA уже плотно вошла в нашу жизнь — это удобно и безопасно. Почему бы не сделать это и на сервере?
Вам нужно установить пакет libpam-google-authenticator — на современных ОС он доступен в штатных репозиториях. После установки пакета запускаем команду:
И утвердительно отвечаем на вопрос:
После чего появится окно с QR-кодом, кодом верификации и резервные пароли:
Сохраняем код себе, добавляем ключ в приложение.
После чего в конфиге /etc/pam.d/sshd добавляем строку:
Меняем в /etc/ssh/sshd_config параметр ChallengeResponseAuthentication на yes
И перезапускаем SSH командой service sshd restart
Теперь при подключении к серверу после ввода пароля будет запрашиваться код подтверждения.
Панели управления
Помимо самого сервера нужно также позаботиться и о доступах в личный кабинет и панель управления сервером. Имея доступ к VNC или кнопкам управления, злоумышленник может, например, переустановить ОС на сервере и все данные будут утеряны. Или бесконечно прожимать кнопку перезагрузки, что тоже неприятно.
В панелях управления Billmanager/VMmanager/DCImanager/ISPmanager вы можете также настроить двухфакторную аутентификацию через Google Autentificator.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
SSH (ч.2): Настройка сервера OpenSSH
Оглавление
Как настроить SSH сервер (sshd)
Служба sshd считывает настройки из конфигурационного файла /etc/ssh/sshd_config. Этот файл содержит пары «ключевое слово — аргумент», одна пара на одной строке. Для каждого ключевого слова будет использовано первое полученное значение (исключение составляют несколько директив, которые можно использовать несколько раз, и каждого значение будет учтено, например это Port и ListenAddress).
Опционально аргументы можно заключить в двойные кавычки («), чтобы передать аргументы, содержащие пробелы.
Ключевые слова не чувствительны к регистру, а аргументы чувствительны к регистру.
Многие директивы закомментированы, но они указывают на значение по умолчанию, которое всё равно используется. Если вас устраивает значение по умолчанию, то не нужно ничего менять. Если же вы хотите другое значение, то нужно раскомментировать строку с соответствующей директивой (убрать символ #) и внести изменения.
Дополнительно можно указать опции командной строки — они имеют приоритет над настройками в конфигурационном файле.
Перезапуск службы SSH
Если между sshd.service и sshd.socket (подробности в разделе «Управление службой OpenSSH») вы выбрали запуск sshd.service, то чтобы внесённые в конфигурационный файл изменения вступили в силу, необходимо перезапустить службу:
Для sshd.socket перезапуск службы требуется только при изменении номера порта (как это показано ниже) и делается так:
Как изменить порт, на котором работает сервер OpenSSH
Все настройки выполняются в файле /etc/ssh/sshd_config или в строке команды запуска sshd.
Для sshd.socket смена прослушиваемого службой порта происходит иначе.
Если вы используете sshd.service (объяснения в первой части), то смена порта также происходит в файле /etc/ssh/sshd_config. Для этого раскомментируйте директиву Port и укажите новое значение:
Опцию Port разрешено использовать несколько раз.
Также порт можно установить с помощью ListenAddress.
Если вы используете сокет sshd.socket и хотите поменять для SSH прослушиваемый порт, то вам нужно редактировать специальный файл следующим образом:
Там можно указать только порт:
Обратите внимание, что использование ListenStream дважды в одном конфигурационном файле не является ошибкой. Если вы используете ListenStream только один раз с указанием порта, тогда будут прослушиваться и 22 порт и порт, который вы указали. Первое использование ListenStream= отключает прослушивание 22 порта.
Для sshd.socket другие настройки, как обычно, в файле /etc/ssh/sshd_config. Но директивы Port и ListenAddress будут игнорироваться (если выбрано прослушивание сокета).
Как выбрать интерфейс (IP) для прослушивания
В системе может быть несколько сетевых интерфейсов с несколькими IP адресами, по умолчанию sshd прослушивает их все, в том числе IPv6 адреса:
Если вы хотите, чтобы компьютер в локальной сети был доступен только для устройств в локальной сети, то можно указать его локальный IP:
Директиву ListenAddress можно использовать несколько раз в одном конфигурационном файле. Разрешены следующие форматы:
Если порт не указан, то sshd будет прослушивать на указанном порту в соответствии со всеми установленными опциями Port в этом файле.
Квалификатор rdomain является необязательным, он имеет отношение к маршрутизации.
Также обратите внимание, что с ListenAddress обязательно должен быть указано имя хоста (адрес) ИЛИ порт. Можно указать отдельно имя хоста (адрес), можно указать отдельно порт, а также можно указать их вместе. Во всех вариантах rdomain может отсутствовать.
Опции командной строки (об их использовании далее) имеют приоритет над директивами конфигурационного файла. В том числе опция для установки используемого порта приводят к тому, что Port в конфигурационном файле игнорируется. Но порты указанные с ListenAddress перезаписывают порты в строке команды.
Вы можете указать конкретный IP, который будет прослушиваться в ожидании подключений. А опцией AddressFamily вы можете выбрать для прослушивания все адреса, только IPv4 или только IPv6:
Почему пользователь root не может подключиться по SSH с верным паролем. Как запретить или разрешить подключение root по SSH
Если при подключении к удалённой системе по SSH вы сталкиваетесь с ошибкой, что не удаётся войти под пользователем SSH даже с верным паролем:
То проверьте значение директивы PermitRootLogin:
По умолчанию она закомментирована, но указанное значение всё равно используется по умолчанию.
Директива PermitRootLogin определяет, может ли root выполнить вход используя ssh. Аргументами могут быть: yes, prohibit-password, forced-commands-only или no. Значением по умолчанию является prohibit-password.
Если эта опция установлена на prohibit-password (или устаревший псевдоним without-password), то вход по паролю и интерактивная аутентификация с клавиатуры отключены для пользователя root.
Если эта опция установлена на forced-commands-only, вход root с аутентификацией по публичному ключу будет разрешён, но только если была указана опция ForceCommand с командой (это может быть полезно для получения удалённых бэкапов, даже если нормальный вход root не разрешён). Все другие методы аутентификации отключены для root.
Если эта опция установлена на no, то root’у не разрешён вход вовсе.
Если опция установлена на yes, то разрешён вход для рута без ограничений.
Итак, если вы столкнулись с проблемой, что не можете выполнить вход с верным паролем под пользователем root, то либо настройте вход без пароля — по публичному ключу, либо установите значение этой директивы на yes.
Запрет и разрешение входа в SSH по паролю обычным пользователям
Чуть выше мы рассмотрели вариант, когда пользователю root запретить вход по паролю. Такую же настройку можно сделать для всех остальных пользователей, для этого используется директива PasswordAuthentication. Значением по умолчанию является yes, то есть вход по паролю разрешён. Для запрета входа по паролю всем пользователям, установите значение этой директивы на no.
Разрешение входа без пароля
За разрешение входа без пароля отвечает директива PermitEmptyPasswords. Она нужна для специфичных случаев, чтобы разрешить вход аккаунтам с пустой парольной строкой. По умолчанию установлена на no.
Как разрешить или запретить пользователям входить через SSH
Всего имеется 4 директивы, которые разрешают или запрещают пользователям и группам подключаться к SSH. Эти директивы в порядке обработки: DenyUsers, AllowUsers, DenyGroups и наконец AllowGroups.
За ключевым словом AllowUsers может следовать список шаблонов имён пользователей, разделённых пробелами, например:
Если директива используется, то вход разрешён только пользователям, имена которых соответствуют шаблонам. Принимаются только имена пользователей, цифровые идентификаторы пользователей не распознаются. По умолчанию вход разрешён для всех пользователей. Если шаблон имеет вид ПОЛЬЗОВАТЕЛЬ@ХОСТ, тогда раздельно проверяются ПОЛЬЗОВАТЕЛЬ и ХОСТ и вход разрешается только определённым пользователям с определённых хостов. В качестве ХОСТа могут быть адреса в формате CIDR, то есть в виде адрес/маска.
Далее о шаблонах, которые могут принимать директивы DenyUsers, AllowUsers, DenyGroups и AllowGroups.
Шаблоны в файле настроек SSH
Шаблон состоит из нуля или более символов, которые не являются белыми пробелами, ‘*’ (подстановочного символа, который соответствует нулю или более символам), а также ‘?’ (подстановочный символ, который соответствует ровно одному любому символу). Например, чтобы охарактеризовать любой хост в наборе доменов «.co.uk» можно использовать следующий шаблон:
Следующий шаблон будет соответствовать любому хосту в сетевом диапазоне 192.168.0.9:
Список шаблонов — это несколько шаблонов, разделённых запятой. Шаблоны внутри списка могут иметь противоположное значение если перед ними стоит восклицательный знак («!»). Например, для разрешения ключа использовать откуда угодно внутри организации, кроме пула «dialup», можно использовать следующее (в authorized_keys):
Помните, что отрицательное совпадение никогда само по себе не даст положительных результатов. Например, попытка сопоставить хост «host3» следующими списку шаблонов не найдёт совпадений:
Решением для предыдущей ситуации является включение термина, который приведёт к положительному совпадению, им может быть подстановочный символ:
Как разрешить подключение только с определённого IP или группы IP. Как заблокировать определённые IP для SSH
С помощью директив (перечислены в порядке обработки) DenyUsers, AllowUsers, DenyGroups и AllowGroups и шаблонов можно настроить разрешения для доступа к SSH по IP.
Рассмотрим несколько примеров. Если в файл sshd_config добавить фильтрацию с AllowUsers:
Это разрешит доступ для johndoe и admin2 только с адресов 192.168.1.*, а для otherid1, otherid2 доступ будет открыт с любого адреса.
Чтобы разрешить доступ к SSH любым пользователям, но только с определённых IP, в файле /etc/ssh/sshd_config используйте директиву AllowUsers с подстановочным символом:
Возможно ограничить ключ ssh или ключ на основе ca набором адресов в файле .ssh/authorized_keys домашнего каталога данного пользователя:
В этом примере открытый ключ для useralias будет действовать только с заданных адресов.
Настройка журналов SSH сервера
Служба SSH не ведёт свой собственный лог и записывает события в системный журнал. О том, как его просмотреть, обратитесь к разделу «Как проверить журнал событий SSH службы».
Можно настроить подробность ведения журнала — уровень вербальности, то есть какие именно сообщения будут записываться в этот журнал. Для этого используется директива LogLevel. Её значем по умолчанию является INFO. Также доступны следующие варианты:
DEBUG и DEBUG1 являются эквивалентами. DEBUG2 и DEBUG3 — каждый указывает на более высокие уровни вывода отладочной информации.
Ведение журнала на уровне DEBUG нарушает политику приватности пользователей и не рекомендуется.
Запуск SSH без отсоединения от терминала
Запуск службы sshd описан в первой части. Также демон sshd можно запустить по имени файла. Для этого нужно указать полный путь до файла sshd, чтобы его узнать:
Запущенная таким образом sshd отключиться от терминала (перейдёт в фоновое выполнение) и не будет выводить что-либо в стандартный вывод.
Можно запустить sshd как процесс без отсоединения от терминала (чтобы процесс не стал демоном), для этого используйте опцию -D — это позволяет упростить процесс мониторинга работы SSH, поскольку сообщения о событиях и проблемах службы будут выводиться в стандартный вывод. Дополнительно можно указать опцию -d для включения режима отладки:
Запуск сервера SSH с другим конфигурационным файлом
С помощью опции -f можно указать путь до другого конфигурационного файла (значение по умолчанию /etc/ssh/sshd_config). sshd откажется запускаться без конфигурационного файла.
Как проверить конфигурационный файл сервера SSH без запуска службы
Тестовый режим. Только проверяет правильность файла конфигурации и работоспособность ключей. Это полезно для надёжного обновления sshd, поскольку параметры конфигурации могут измениться.
Расширенный тестовый режим. С этой опцией sshd проверит правильность файла конфигурации, выведет действующую конфигурацию в стандартный вывод и затем завершит работу. При желании, правила соответствия могут применяться путём указания параметров соединения с использованием одной или нескольких опций -C.
-C connection_spec
Другие важные опции командной строки сервера SSH
-c host_certificate_file
Указывает путь к файлу сертификата для идентификации sshd во время обмена ключами. Файл сертификата должен соответствовать файлу ключа хоста, указанному с помощью параметра -h или директивы конфигурации HostKey.
-h host_key_file
Указывает файл, из которого читается ключ хоста. Эта опция должна быть указана, если sshd не запускается от имени пользователя root (поскольку обычные файлы ключей хоста как правило не читаются никем, кроме root). По умолчанию это /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key и /etc/ssh/ssh_host_rsa_key. Можно иметь несколько файлов ключей хоста для разных алгоритмов ключей хоста.
-E файл_журнала
Добавить журналы отладки в файл_журнала вместо системного журнала.
Записывать журналы отладки в стандартный вывод ошибок вместо системного журнала.
-o опция
Может использоваться для задания параметров в формате, используемом в файле конфигурации (sshd_config). Это полезно для указания параметров, для которых нет отдельного флага командной строки. Самые важные директивы конфигурационного файла рассмотрены выше.
-p порт
Указывает порт, на котором сервер прослушивает соединения (по умолчанию 22). Допускается использование нескольких портов. Порты, указанные в файле конфигурации с параметром «Port», игнорируются, если указан порт командной строки. Порты, указанные с помощью параметра ListenAddress, переопределяют порты командной строки.
Тихий режим. Ничего не отправляется в системный журнал. Без этой опции обычно запуск, аутентификация и завершение каждого соединения регистрируются.
Другие опции sshd
Рассмотрены самые востребованные опции конфигурационного файла sshd, кроме них имеется ещё много других, которые настраивают используемые шифры, могут более тонко определить порядок аутентификации и требования к подключающемуся, настраивают возможности пересылки (forwarding), установить выполняемую команду при подключении пользователя, вывод определённой информации при подключении и так далее.
С другими опциями конфигурационного файла sshd (на английском языке) вы сможете ознакомиться с помощью команды:
Информацию об опциях командной строки можно увидеть с помощью:
Денис Туляков wiki
Настройка сервера
Для того что бы не тормозил вход по ssh в конфиге надо указать «UseDNS no»
При установке SSH-сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:
Основной файл конфигурации SSH-сервера — файл /etc/ssh/sshd_config, доступный для чтения или редактирования только суперпользователю. После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.
Пример конфигурации SSH-сервера в Ubuntu по умолчанию2):
Port, ListenAddress и AddressFamily
Эти три параметра определяют, на каких портах и адресах ваш сервер будет ждать входящие соединения. Во-первых, имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 — отключите IРv6, и наоборот. Сделать это можно при помощи параметра AddressFamily, например (для разрешения IPv4 и запрета IPv6):
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port, так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress. Например:
Запрещение удаленного доступа для суперпользователя по паролю
Парольная аутентификация
Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:
Если по каким либо причинам вам все таки хочется использовать парольную аутентификацию — позаботьтесь о том, чтобы никто не мог авторизоваться с пустым паролем. Для этого задайте директиву PermitEmptyPasswords:
Протоколы SSH1 и SSH2
Как уже было сказано, sshd может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить sshd работать только с протоколом SSH2 можно так:
Аутентификация на основе SSH2 RSA/DSA-ключей
Наиболее предпочтительным способом авторизации является аутентификация на основе SSH2 RSA, DSA, ECDSA, ED25519 ключей. При таком способе пользователь генерирует на своей стороне пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ копируется на сервер и служит для проверки идентичности пользователя. Более подробно про создание пары ключей и способы размещения их на сервере см. в описании SSH-клиента. Включить аутентификацию по публичному ключу можно так:
Сервер должен знать, где ему следует искать публичный ключ пользователя. Для этого применяется специальный файл authorized_keys. Синтаксис его может быть следующим:
Можно указать как один общий файл с ключами, так и по файлу на каждого пользователя. Последний способ является более удобным и безопасным, т. к. можно во-первых указывать разные комбинации ключей для каждого пользователя4), а во-вторых ограничить доступ к публичному ключу пользователя. Задать файл с ключами можно при помощи директивы AuthorizedKeysFile:
