Ubuntu ограничение ssh по ip

Обновлено: 01.07.2024

Серверы Linux часто управляются удаленно с использованием протокола SSH путем подключения к серверу OpenSSH, который является программным обеспечением сервера SSH по умолчанию, используемым в Ubuntu, Debian, CentOS, FreeBSD и большинстве других систем на базе Linux/BSD.

Сервер OpenSSH — это серверная сторона SSH, также известная как демон SSH или sshd . Вы можете подключаться к серверу OpenSSH, используя клиент OpenSSH, а именно команду ssh . Дополнительную информацию о модели клиент-сервер SSH можно найти в статье Основы SSH: работа с серверами, клиентами и ключами SSH. Надлежащая защита вашего сервера OpenSSH имеет большое значение, поскольку сервер является центральным входом или «дверью» на ваш сервер.

В этом обучающем руководстве мы усилим защиту вашего сервера OpenSSH с помощью различных вариантов конфигурации для обеспечения максимально безопасного удаленного доступа к вашему серверу.

Предварительные требования

Для данного обучающего руководства вам потребуется следующее:

Сервер Ubuntu 18.04, настроенный согласно руководству по первоначальной настройке сервера с Ubuntu 18.04, включая пользователя sudo без прав root.

Подготовив все вышеперечисленное, войдите на сервер в качестве пользователя без прав root, чтобы начать работу.

Шаг 1 — Общее усиление защиты

На этом первом шаге мы используем некоторые первоначальные конфигурации усиления защиты для повышения общей безопасности вашего сервера SSH.

Какая именно конфигурация максимально подходит вашему серверу, зависит в значительной мере от вашей модели угроз и порога риска. Однако конфигурация, которую вы будете использовать на этом шаге, — это общая конфигурация безопасности, подходящая для большинства серверов.

Многие из конфигураций усиления защиты для OpenSSH внедряются с использованием стандартного файла конфигурации сервера OpenSSH, который находится в каталоге /etc/ssh/sshd_config . Прежде чем продолжить, рекомендуем сделать резервную копию вашего существующего файла конфигурации, чтобы вы могли его восстановить, если что-то пойдет не так, хоть это и маловероятно.

Сделайте резервную копию с помощью следующей команды:

Резервная копия файла будет сохранена в /etc/ssh/sshd_config.bak .

Перед редактированием файла конфигурации вы можете просмотреть текущие настроенные опции. Сделать это можно с помощью следующей команды:

При этом сервер OpenSSH будет запущен в расширенном тестовом режиме, в ходе которого будет проверен полный файл конфигурации и выведены эффективные значения конфигурации.

Теперь вы можете открыть файл конфигурации с помощью предпочитаемого текстового редактора и начать реализовывать первоначальные меры по усилению защиты:

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

Сначала отключите возможность входа через SSH в качестве пользователя с правами root, установив следующую опцию:

Это крайне полезная опция, так как она не дает потенциальным злоумышленникам возможности входа непосредственно в качестве пользователя с правами root. Она также поощряет использование передовых методов оперативной безопасности, таких как работа в качестве пользователя без привилегий и использование sudo для повышения привилегий только в случае крайней необходимости.

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

Стандартное значение 3 приемлемо для большинства настроек, но вы можете увеличить или уменьшить его в зависимости от вашего порога риска.

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

Файл конфигурации определяет это значение в секундах.

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

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

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

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

Если вы хотите узнать больше о некоторых дополнительных методах аутентификации, имеющихся в SSH, вы можете ознакомиться с этими ресурсами:

Перенаправление X11 позволяет отображать удаленные графические приложения через подключение SSH, но это редко используется на практике. Рекомендуется отключить эту опцию, если она не требуется на вашем сервере:

Сервер OpenSSH позволяет подключать клиентов для прохождения переменных настраиваемой среды, т. е. устанавливать $PATH или конфигурировать настройки терминала. Однако, как и перенаправление X11, эти опции не имеют широкого распространения, поэтому могут быть отключены в большинстве случаев:

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

Наконец, вы можете отключить активированный по умолчанию подробный баннер SSH, поскольку в нем представлена различная информация о вашей системе, например версия операционной системы:

Обратите внимание, что эта опция, скорее всего, не будет изначально представлена в файле конфигурации, поэтому вам придется добавить ее вручную. Сохраните и закройте файл после завершения.

Теперь проверьте синтаксис новой конфигурации, запустив sshd в тестовом режиме:

Если у вашего файла конфигурации допустимый синтаксис, вывода не будет. В случае ошибки синтаксиса появится вывод с описанием проблемы.

Когда вы настроили файл конфигурации в соответствии с вашими потребностями, можно перезагрузить sshd , чтобы применить новые настройки:

На этом шаге вы выполнили некоторые действия по общему усилению защиты файла конфигурации сервера OpenSSH. На следующем шаге мы создадим список разрешенных IP-адресов для дальнейшего ограничения возможности входа на ваш сервер.

Шаг 2 — Внедрение списка разрешенных IP-адресов

Вы можете использовать списки разрешенных IP-адресов для ограничения числа пользователей, имеющих разрешение входить на ваш сервер с помощью IP-адреса. На этом шаге вы настроите список разрешенных IP-адресов для вашего сервера OpenSSH.

Зачастую вы будете входить на сервер с ограниченного числа известных доверенных IP-адресов. Например, это может быть ваше домашнее интернет-подключение, корпоративное оборудование VPN, статический инсталляционный сервер или узел-бастион в ЦОД.

Внедряя список разрешенных IP-адресов, вы можете быть уверены, что в систему можно войти только с одного из предварительно одобренных IP-адресов, что значительно снижает риск проникновения в случае утечки ваших частных ключей и/или паролей.

Примечание. Обязательно проверьте корректность IP-адресов, которые вы добавляете в список. Убедитесь, что эти адреса не являются плавающими или динамическими, которые могут регулярно меняться. Данная функция, например, часто встречается у поставщиков интернет-услуг.

Вы можете определить текущий IP-адрес, с которого вы подключаетесь к вашему серверу, с помощью команды w :

Будет выведен текст следующего вида:

Найдите в списке вашу учетную запись пользователя и отметьте связующий IP-адрес. В данном случае мы используем в качестве примера IP-адрес 203.0.113.1 .

Чтобы внести ваш IP-адрес в список разрешенных адресов, откройте файл конфигурации сервера OpenSSH в предпочитаемом текстовом редакторе:

Вы можете создавать списки разрешенных IP-адресов с помощью директивы конфигурации AllowUsers , которая ограничивает аутентификацию пользователя на основе имени пользователя и/или IP-адреса.

Какая именно конфигурация подходит больше всего, зависит от настроек вашей системы и требований. Следующие примеры помогут вам определить наиболее подходящую конфигурацию:

Ограничить всех пользователей конкретным IP-адресом:

Ограничить всех пользователей конкретным диапазоном IP-адресов с помощью записи бесклассовой междоменной маршрутизации (CIDR):

Ограничить всех пользователей конкретным диапазоном IP-адресов (с помощью подстановочных знаков):

Ограничить всех пользователей несколькими конкретными IP-адресами и диапазонами:

Запретить вход всем пользователям, кроме указанных пользователей с конкретных IP-адресов:

Ограничить конкретного пользователя конкретным IP-адресом, сохраняя возможность для всех других пользователей входить без ограничений:

Предупреждение. В файле конфигурации OpenSSH все конфигурации в блоке Match будут применяться только к подключениям, которые соответствуют критериям, независимо от отступов и разрывов строк. Это означает, что вы должны быть осторожны и убедиться, что конфигурации, предназначенные для глобального применения, не попали в блок Match . Чтобы избежать этого, рекомендуется поставить все блоки Match в самом низу/конце файла конфигурации.

После завершения установки конфигурации добавьте ее внизу файла конфигурации сервера OpenSSH:

Сохраните и закройте файл, а затем перейдите к проверке синтаксиса конфигурации:

Если ошибок не выявлено, можно перезагрузить сервер OpenSSH для применения конфигурации:

На этом шаге вы внедрили список разрешенных IP-адресов на вашем сервере OpenSSH. На следующем шаге мы ограничим оболочку пользователя, чтобы сократить количество команд, разрешенных к использованию.

Шаг 3 — Ограничение оболочки пользователя

На этом шаге вы рассмотрите различные опции ограничения оболочки пользователя SSH.

Помимо предоставления удаленного доступа к оболочке, SSH также имеет большое значение для передачи файлов и других данных, например через SFTP. Однако вам не всегда нужно обеспечивать полный доступ к оболочке пользователям, если им требуется только иметь возможность выполнять передачу файлов.

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

Во-первых, вы можете использовать оболочку /usr/sbin/nologin для отключения интерактивных логинов для некоторых учетных записей пользователей, при этом оставляя возможность выполнения неинтерактивных сеансов, таких как передача файлов, настройка туннелей и т. д.

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

Также вы можете изменить оболочку существующего пользователя на nologin :

Если после этого вы попытаетесь интерактивно войти в систему как один из этих пользователей, запрос будет отклонен:

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

Начните с открытия файла конфигурации сервера OpenSSH в вашем любимом текстовом редакторе:

Есть две опции конфигурации, которые вы можете реализовать совместно для создания строго ограниченной учетной записи пользователя только SFTP: ForceCommand internal-sftp и ChrootDirectory .

Опция ForceCommand внутри сервера OpenSSH заставляет пользователя выполнять конкретную команду при входе в систему. Это может быть полезно для определенных межкомпьютерных коммуникаций или для принудительного запуска конкретной программы.

Однако в данном случае команда internal-sftp имеет особую значимость. Это специальная функция сервера OpenSSH, запускающая базовый демон SFTP, который не требует каких-либо вспомогательных системных файлов или конфигураций.

В идеале ее следует сочетать с опцией ChrootDirectory , которая будет переопределять/изменять воспринимаемый корневой каталог для конкретного пользователя, по сути, ограничивая его конкретным каталогом в системе.

Добавьте для этого следующий раздел конфигурации в файл конфигурации сервера OpenSSH:

Предупреждение. Как отмечается в шаге 2, в файле конфигурации OpenSSH все конфигурации в блоке Match будут применяться только к подключениям, которые соответствуют критериям, независимо от отступов и разрывов строк. Это означает, что вы должны быть осторожны и убедиться, что конфигурации, предназначенные для глобального применения, не попали в блок Match . Чтобы избежать этого, рекомендуется поставить все блоки Match в самом низу/конце файла конфигурации.

Сохраните и закройте файл конфигурации и снова протестируйте конфигурацию:

Если ошибок нет, вы можете внедрять конфигурацию:

Так вы создали надежную конфигурацию для пользователя alex , где отключен интерактивный логин, а вся активность SFTP ограничена домашним каталогом пользователя. С точки зрения пользователя корнем системы, т. е. / , является домашний каталог, и нельзя пройти через файловую систему, чтобы получить доступ к другим областям.

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

Шаг 4 — Расширенное усиление защиты

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

Менее известная особенность сервера OpenSSH — это возможность вводить ограничения на основе ключа, т. е. ограничения, применимые только к отдельным публичным ключам, представленным в файле .ssh/authorized_keys . Это особенно полезно для контроля доступа к межкомпьютерным сеансам, а также предоставления пользователям без привилегий sudo контроля ограничений их собственных учетных записей.

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

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

Для начала откройте файл .ssh/authorized_keys в предпочитаемом текстовом редакторе:

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

После открытия файла authorized_keys вы увидите, что каждая строка содержит публичный ключ SSH, который, скорее всего, будет начинаться с ssh-rsa AAAB. . Дополнительные опции конфигурации можно добавить в начало строки, и они будут применяться только к успешным случаям аутентификации с помощью конкретного публичного ключа.

Доступны следующие опции ограничения:

no-agent-forwarding : отключение перенаправления агента SSH.
no-port-forwarding : отключение перенаправления порта SSH.
no-pty : отключение возможности выделения tty (т. е. запуск оболочки).
no-user-rc : предотвращение выполнения файла

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

По умолчанию эти конфигурации работают с помощью методологии «разрешено по умолчанию, блокируется в виде исключения». Однако можно использовать вариант «блокируется по умолчанию, разрешено в виде исключения», что обычно более предпочтительно для обеспечения безопасности.

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

Например, для отключения всех функций SSH для конкретного ключа, помимо перенаправления графического сеанса X11, вы можете использовать следующую конфигурацию:

Также вы можете рассмотреть возможность использования опции command , которая очень похожа на опцию ForceCommand , описанную в шаге 3. Это не дает прямой пользы, если вы уже используете ForceCommand , но представляет хорошую возможность обеспечить глубокую защиту в маловероятном случае, когда ваш основной файл конфигурации сервера OpenSSH был переписан, отредактирован и т. д.

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

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

Наконец, для максимально продуктивного использования ограничения по ключу для пользователя только SFTP, которое вы настроили на шаге 3, используйте следующую конфигурацию:

Опция restrict отключает любой интерактивный доступ, а опция command="false" действует как вторая линия защиты в случае отказа опции ForceCommand или оболочки nologin .

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

На этом заключительном шаге вы внедрили некоторые дополнительные усовершенствованные меры по усилению защиты для сервера OpenSSH, используя настраиваемые опции внутри файла (файлов) .ssh/authorized_keys .

Заключение

В этой статье вы рассмотрели конфигурацию сервера OpenSSH и приняли различные меры по усилению защиты для обеспечения безопасности вашего сервера.

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

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

Как мы разрешаем определенному набору частных IP-адресов входить через Linux SSH (пара ключей RSA) в Linux Server?

firewall или /etc/hosts.allow, если ssh компилирует с оболочками TCP / или / etc / ssh / sshd_config правила файла.

Вы можете ограничить количество подключаемых хостов, настроив оболочки TCP или отфильтровав сетевой трафик (межсетевой экран) с помощью iptables . Если вы хотите использовать разные методы аутентификации в зависимости от IP-адреса клиента, настройте демон SSH (вариант 3).

Вариант 1: фильтрация с помощью IPTABLES

Правила Iptables оцениваются по порядку, до первого совпадения.

Например, чтобы разрешить трафик из сети 192.168.0.0/24 и в противном случае отбросить трафик (на порт 22). DROP Правила не требуется , если ваша политика Iptables по умолчанию настроена на DROP .

Вы можете добавить больше правил перед правилом удаления, чтобы соответствовать большему количеству сетей / хостов. Если у вас много сетей или адресов хостов, вы должны использовать модуль ipset . Также есть модуль iprange, который позволяет использовать любой произвольный диапазон IP-адресов.

Iptables не сохраняется при перезагрузке. Вам нужно настроить механизм восстановления iptables при загрузке.

iptables применять только к трафику IPv4. Системы, в которых ssh прослушивает IPv6-адрес, могут быть выполнены с необходимой конфигурацией ip6tables .

Вариант 2. Использование TCP-оболочек

Вы также можете настроить, какие хосты могут подключаться, используя TCP-оболочки. С оболочками TCP, помимо IP-адресов, вы также можете использовать имена хостов в правилах.

По умолчанию запрещены все хосты.

Затем список разрешенных хостов в hosts.allow. Например, чтобы разрешить сеть 192.168.0.0/24 и localhost .

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

Вы можете настроить демон ssh в sshd_config для использования другого метода аутентификации в зависимости от адреса клиента / имени хоста. Если вы хотите заблокировать подключение только других хостов, вам следует использовать оболочки iptables или TCP.

Сначала удалите методы аутентификации по умолчанию:

Затем добавьте нужные методы аутентификации после a Match Address в конце файла. Размещение Match в конце файла важно, так как все строки конфигурации после него помещаются в условный блок до следующей Match строки. Например:

Другие клиенты по-прежнему могут подключаться, но вход в систему не удастся, потому что нет доступных методов проверки подлинности.

Аргументы соответствия и допустимые параметры условной конфигурации описаны в справочной странице sshd_config . Шаблоны соответствия описаны в справочной странице ssh_config .

Бывают такие задачи, когда нужно ограничить доступ к терминалу ssh пользователей, чтобы нельзя было вводить команды, просматривать файлы, запускать командер mc. В общем, ничего нельзя делать.

Или возможен другой вариант, запретить доступ на вход пользователя по IP-адресу.

Прежде всего хочется ответить на вопрос зачем это нужно?

Безопасность. Уменьшается вероятность проникновения в систему, через сетевой протокол прикладного уровня ssh.
Для туннеля, который создан посредством ssh соединения. Например необходимо организовать удаленный доступ на локальную машину под управлением windows через шлюз Linux. В этом случаи неправильно давать пользователю доступ в shell /bin/bash.

Рассмотрим три варианта ограничения Secure Shell:

Запретить доступ по протоколу ssh. В этом случаи туннель не будет работать, однако для примера рассмотрим этот способ тоже.
Запрещаем по IP-адресу. То есть могут подключиться только те, чьи IP разрешены.
Меняем shell по умолчанию конкретному пользователю и пишем бесконечный цикл на bash языке.

ssh что это?

ssh (Secure Shell) - сетевой протокол, который позволяет удаленно подключаться к операционной системе, а также производить туннелирование.

В операционной системе Линукс за протокол отвечает ПО OpenSSH.

Здесь же рассмотрим конкретные задачи ограничения доступа.

Запрет на вход по протоколу

Можно добавить в ssh_users список пользователей, которым разрешен доступ по ssh, то есть всем остальным запрещен.

или можно конфиге добавить директиву:

AllowUsers user1, User2

Где user1 и user2 - имена пользователей.

ssh ограничение доступа по IP

Чтобы ограничить подключение (Secure Shell) по IP-адресу, необходимо отредактировать два файла /etc/hosts.allow и /etc/hosts.deny.

/etc/hosts.allow - здесь указываем разрешенные IP-адреса.

Меняем на:
sshd: 127.0.0.1
где 127.0.0.1 - ваш IP.

Далее в /etc/hosts.deny пишем:
sshd: ALL

Такой вариант идеально подойдет для туннелирование TCP-соединений. Когда в консоль зайти нужно, а вводить команды нет.

В файл /etc/ssh/ssh_users добавляем пользователя. В моем случае это usertunnel.

Создадим скрипт zbash, через редактор nano.

У меня стоит роутер и фарвол на Linux Red-hat с IPTABLES я хочю что-бы к сервису SSH только с определёных IP был доступ а не всем и всям .. блин достали ломится всякие .. Как лучше поступить в этой ситуаций . Спасиба тому кто ответить.

iptables -A INPUT -p tcp --dport 22 -s !10.0.0.0/24 -j DROP

Запретит подключения всем, кроме сети 10.0.0.0/24

А если я хочю сделать только с определённых IP и в локалке и ешё я из дома выхожу через прова в инет и у меня нет выделенного IP Вот такие жёсткие условия хочю сделать !

я читал что DROP не совсем правильнно а лучше REJECT ..

Если я не ошибаюсь, то в sshd_config можно указывать адреса.

Нее, там только по юзерам и группам фильтровать можно

Если sshd собирался с поддержкой tcp-wrappers или запускается через tcpd, то можно список адресов, с которых "вход разрешен", указать в /etc/hosts.allow:
sshd: 127.0.0.1, 192.168., x.x.x.x
sshd: y.y.y.y, z.z.z.z
а в /etc/hosts.deny - запрет всем остальным:
sshd: ALL

>я читал что DROP не совсем правильнно а лучше REJECT ..

Я, например, практически не знаю случаев когда следует использовать REJECT. Так что советую DROP

если ssh собран с tcp wrappers (а это обучно так), можно прочитать man hosts_access и обойтись малой кровью.

> Я, например, практически не знаю случаев когда следует использовать REJECT. Так что советую DROP

Например, для DNS и ident.

хм, я сделал зонуи адресов которые элита, к примеру они выдаются только моей машине серверу, и можему, в апитаблах настроил что ССАШ пускает толко с этой группы (ну или эта группа маскируется к какой то 1 ip и пускается только он) и все.

Читайте также: