🖧 Ограничение SSH в локальной сети в Linux |

🖧 Ограничение SSH в локальной сети в Linux

Закрытие уязвимостей

SSH – один из основных сервисов, используемых для администрирования, поэтому любые угрозы его безопасности не должны восприниматься легкомысленно.

В этом руководстве мы рассмотрим, как ограничить SSH локальной сетью в Linux.

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

Ограничение SSH в локальной сети – один из способов сделать это.

Особенно важно позаботиться о безопасности SSH в производственных средах.

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

Кроме того, полезно применять принцип наименьших привилегий и разрешать доступ к порту SSH только известным источникам.

IPables

Самый распространенный способ защитить Linux-хост от получения нежелательных сетевых подключений – создать правила брандмауэра хоста.

Итак, мы начнем с создания правила, обеспечивающего строгие правила контроля доступа к TCP-порту службы SSH.

Мы можем сделать это с помощью команды iptables:

sudo iptables -A INPUT -s 10.1.2.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -m comment --comment ssh -j ACCEPT

Это выдаст системе Linux указание принимать только соединения с портом службы SSH (TCP/22), исходящие из подсети 10.1.2.0/24.

Чтобы сделать это правило iptables постоянным, мы можем установить пакет iptables-persistent (в системах на базе Debian, таких как Ubuntu) и сохранить все существующие правила в его конфигурации:

🖧 Как навсегда сохранить правила брандмауэра iptables на Linux

Установите пакет IPTables-persistent
sudo apt install iptables-persistent
Добавьте текущие правила IPtables в его конфигурацию
sudo iptables-save > /etc/iptables/rules.v4

Это позволит применять правило защиты при каждом перезапуске системы.

Ограничение с помощью sshd_config

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

Разрешение и запрет подключений с определенных IP-адресов

Чтобы настроить демон SSH на запрет соединений из любых ненадлежащих источников, мы можем добавить следующие директивы в конфигурационный файл демона SSH, обычно расположенный по адресу /etc/ssh/sshd_config или /etc/openssh/sshd_config:

Это запретит всем
AuthorizedKeysFile /dev/null
# Вставьте сюда сетевую маску, которую вы хотите разрешить.
Match Address 10.1.2.0/24
# Соединения с вышеуказанного IP могут использовать обычные авторизованные ключи для аутентификации
AuthorizedKeysFile %h/.ssh/authorized_keys

Первая незакомментированная директива, указывающая AuthorizedKeysFile на /dev/null, запрещает любой доступ к SSH-серверу.

Директива Match Address создает исключение для хостов, расположенных в подсети 10.1.2.0/24, которые должны использовать стандартную конфигурацию AuthorizedKeysFile.

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

Таким образом, она все еще имеет некоторый потенциал для эксплуатации.

Указание сетевых адресов, которые могут прослушивать SSH-соединения

Также предположим, что у нас есть хост с несколькими сетевыми адресами

. В этом случае мы можем использовать директиву ListenAddress, чтобы указать демону SSH прослушивать соединения только на определенном IP-адресе (по умолчанию он прослушивает любой адрес):

# Ограничим адрес прослушивания одним конкретным адресом хоста
ListenAddress 10.1.2.20

Это сузит поверхность атаки, особенно если сеть адресов прослушивания не изолирована от небезопасных сетей.

Заключение

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

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

Мы рассмотрели несколько вариантов защиты нашего SSH-сервера, ограничивающих доступ к локальной сети.

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

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

см. также:

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий