Как отключить переадресацию локального порта SSH?


20

У меня есть сервер под управлением Ubuntu и демон OpenSSH. Давайте назовем это S1.

Я использую этот сервер с клиентских машин (назовем одну из них C1) для создания обратного туннеля SSH с использованием переадресации удаленных портов, например:

ssh -R 1234:localhost:23 login@S1

На S1 я использую файл sshd_config по умолчанию. Из того, что я могу видеть, кто имея правильные учетные данные для входа {, PWD} на S1 может войти в S1 и либо сделать удаленное перенаправление портов и локальное перенаправление портов. Такие учетные данные могут стать сертификатом в будущем, поэтому, насколько я понимаю, любой, кто получает сертификат, может войти в S1 из любого места (не обязательно C1) и, следовательно, создать переадресацию локальных портов.

Для меня разрешить переадресацию локальных портов слишком опасно, так как это позволяет создать какой-то публичный прокси. Я ищу способ отключить только -L пересылки.

Я попробовал следующее, но это отключает как локальную, так и удаленную пересылку:

AllowTcpForwarding No

Я также попробовал следующее, это позволит только -L для SX: 1. Это лучше, чем ничего, но все же не то, что мне нужно, а вариант «нет».

PermitOpen SX:1

Поэтому мне интересно, есть ли способ, чтобы я мог запретить всем форвардам локальных портов писать что-то вроде:

PermitOpen none:none

Это хорошая идея?

PermitOpen localhost:1

так что, как всегда, давайте разберемся с корнем этого: в чем ваша настоящая проблема, почему вы хотите настроить что-то подобное для мобильных / встроенных устройств, что вы хотите решить?
Акира

Проблема, которую необходимо решить, заключается в том, чтобы иметь возможность открывать сеанс Telnet из любого места в Интернете на мобильное / встроенное устройство, подключенное к Интернету, принимая во внимание, что устройство может быть с NAT или брандмауэром, поэтому недоступно из Интернета.
ШОС

телнет .. зачем? для пробивания дыр в брандмауэре Google для «оглушение»
Акира

Ответы:


16

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

% /usr/sbin/sshd -d -f mysshd.config -p 12345

если вы не доверяете пользователям делать что-то с вашей машиной, то вы не должны позволять им входить в систему.

(кстати, флаг -D также является своего рода «проблемным с прокси»)


Ну, я думаю, я могу настроить очень ограниченную учетную запись для этой цели (например, привязать пользователя к его дому, без списка, без просмотра файловой системы), чтобы он не мог запускаться и sshd (или устанавливать и запускать бинарный файл sshd). Дело в том, что клиенты должны быть встроенными устройствами. Но поскольку они, вероятно, будут иметь встроенные сертификаты, а их флэш-памятки могут быть сброшены, возможно, сертификаты будут утечки, что позволит любому войти в S1.
ШОС

Использование ChrootDirectory для этого конкретного пользователя поможет, попробуем!
ШОС

1
В авторизованных ключах установите command="/sbin/nologin". Это должно помешать им запускать любые команды на сервере.
Юстис

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

3
Цитата со sshd_configстраницы руководства: обратите внимание, что отключение пересылки TCP не повышает безопасность, если пользователям также не запрещен доступ к оболочке , поскольку они всегда могут установить свои собственные серверы пересылки. (Акцент мой).
Каз

17

Другое решение - разрешить переадресацию портов только конкретным пользователям:

От SSH: полное руководство

Переадресация портов может быть включена или отключена глобально в sshd. Это делается с помощью ключевого слова конфигурации AllowTcpForwarding в / etc / sshd_config. Ключевое слово может иметь значение yes (по умолчанию, включение пересылки) или no (отключение пересылки):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

Кроме того, SSH2 имеет следующие параметры:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

Их синтаксис такой же, как и для параметров AllowUsers и AllowGroups. [Раздел 5.5.2.1, «Контроль доступа к учетной записи»] Они указывают список пользователей или групп, которым разрешено использовать переадресацию портов; сервер отказывается выполнять запросы перенаправления портов для кого-либо еще. Обратите внимание, что они относятся к целевой учетной записи сеанса SSH, а не к имени пользователя клиента (которое часто неизвестно).

...

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


1
По сути, на S1 будет настроен только один пользователь. AFAIU, в данном конкретном случае, использование AllowTcpForwardingForUsers / AllowTcpForwardingForGroups не поможет, не так ли? Запретить интерактивный вход в систему - это хорошая идея, так как это не позволит пользователям запускать двоичные файлы. Но любому клиенту все равно будет разрешено использовать синтаксис -L, верно? Итак, на данный момент лучшими вариантами будут: 1 / Отключить интерактивный вход в систему, 2 / PermitOpen с поддельным именем хоста: порт. Я что-то пропустил ?
ШОС

Лучший способ убедиться в этом - попробовать выполнить настройку.
Кристиан

Я не вижу этих опций в бесплатном программном обеспечении OpenSSH. Google для AllowTcpForwardingForUsersпоказывает, что он настроен в sshd2_config, который используется в некоторых коммерческих программах. См. Один из ответов на: superuser.com/questions/384643/…
Каз

^ OpenSSH имеет Matchблоки в конфигурации. Вы можете Matchна пользователей и групп, и приложить AllowTcpForwardingвнутри.
Каз

2

Теперь есть возможность разрешить только локальную / удаленную пересылку.

AllowTcpForwarding Указывает, разрешена ли пересылка TCP. Доступные опции: «да» или «все», чтобы разрешить пересылку TCP, «нет», чтобы запретить всю пересылку TCP, «локальный», чтобы разрешить только локальную (с точки зрения ssh (1)) пересылку, или «удаленный», чтобы разрешить удаленную пересылку. только пересылка . По умолчанию «да». Обратите внимание, что отключение пересылки TCP не повышает безопасность, если пользователям также не запрещен доступ к оболочке, поскольку они всегда могут установить свои собственные серверы пересылки.

Итак, как уже говорилось, вы также должны установить оболочку на нологин.


0

Мое решение этой проблемы было добавить: PermitOpen fo.local: 80 в основной раздел sshd_config.

Это просто отклоняет любой запрос локальной пересылки, кроме fo.local: 80.


0

Я ищу способ отключить только -L пересылки

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

«Локальная переадресация портов», разрешенная SSH, является лишь одним из возможных способов сделать это. Другие включают запуск экземпляра socat,netcat или любое другое количество инструментов.

Лучший способ контролировать исходящие и входящие соединения в Linux - это Netfilter, он же IPTables.

Он имеет специальный модуль под названием owner ( ipt_owner), который позволяет сопоставлять различные характеристики создателя пакета для локально сгенерированных пакетов. Это действительно в OUTPUTиPOSTROUTING цепях.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.