Вопросы Теги

Как я могу безопасно создать туннель autossh от ненадежного сервера к доверенному серверу?

Предположим, у вас есть полу-доверенная машина (например, та, к которой у ИТ-отдела вашего бизнес-партнера есть root-доступ), которая находится за брандмауэром, и вы хотите подключиться к этой машине с одной из ваших доверенных машин.

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

Чтобы сделать это в некоторой степени безопасным, в настоящее время я создаю пользователя autossh на обеих машинах и авторизую его открытый ключ без парольной фразы, чтобы пользователь autossh мог установить соединение без необходимости вводить кодовую фразу. Кроме того, я установил оболочку этого пользователя на / bin / false , поскольку это запрещает нормальный вход в систему, по-прежнему позволяя настроить туннель.

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

Хотя злоумышленник, имеющий доступ к полу-доверенному компьютеру, не может войти на доверенный сервер, используя этот ключ, он может, например, выполнить атаку типа «отказ в обслуживании», создав туннельный цикл SSH и лавинно заполнив таблицу открытых файлов (см., например, 1 ) следующим образом 

ssh -vN -L4141:localhost:4141 trustedhost
ssh -vN -R4141:localhost:4141 trustedhost
telnet localhost 4141

И, вероятно, есть и другие возможные атаки. Итак, как я могу дополнительно защитить этот механизм создания этого полу-доверенного туннеля? Мне нужно установить только одно постоянное соединение между этими серверами, никакие другие команды / туннели не нужно выполнять / устанавливать пользователем autossh .

1
задан 11 March 2019 в 10:05
1 ответ

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

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

$ ulimit -n
1024
$ ulimit -u
2048

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

Если вы хотите уменьшить поверхность атаки, прекратите использовать autossh (программа, предназначенная для устранения исторических недостатков, которые были устранены в openssh десять лет назад) и запретите использование TCP-портов на вашей стороне (сокетов unix вполне достаточно для поддержания туннеля). 

Match Group untrusted
  ChrootDirectory /run/empty/%u
  AllowTcpForwarding no
  AllowStreamLocalForwarding remote
  PermitTunnel no

Риски, которые вы, возможно, не сможете уменьшить:

  • кто-то перегружает вашу сетевую ссылку (которая может использоваться совместно с сервисами, которые вам небезразличны)
  • уязвимости повышения привилегий на вашем ssh-сервере
]
0
ответ дан 4 December 2019 в 03:11

Теги

Похожие вопросы